[M3devel] malloc/free from Modula-3?

[Daniel Alejandro Benavides D.]

Hi all:
this unsound trend is what it makes software development uncontrolled, so many unstable codes, it has an effect as Dr Nelson said software quality and perhaps more dangerous ever more, at least with Modula-3 you can keep it under certain control you know are restricted but this is the result of that, their codes are broken then why one need to fix them if it's worse than before. What a mess if so.
Thanks in advance

--- El lun, 18/4/11, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribió:

> De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
> Asunto: Re: [M3devel] malloc/free from Modula-3?
> Para: "Mika Nystrom" <mika at async.caltech.edu>
> CC: m3devel at elegosoft.com
> Fecha: lunes, 18 de abril, 2011 15:18
> Hi all:
> yes pthread allocation must keep their pthread under system
> constraints, but per thread user space the outer space is
> limited, then that's why perhaps RT is breaking due system
> behaviour not by its own consideration, if I may say so, so
> perhaps this is just the unsafe pattern break codes showed,
> since the implementation is responsible for avoiding this
> flaws but assuming they satisfies their restrictions, which
> is modularly sound, but if not then somebody either doesn't
> guarantee our assumptions, or can't meet their
> specifications and ours too so don't assume they satisfy
> theirs own ones too.
> Then in fact would explain why there are many crash
> patterns around which is very system dependent not us
> (that's why I favour one implementation per target source,
> mixing both is like meeting their specifications and so like
> if it would be our goal, correct if I'm wrong here please).
> Anything else is just falling apart of breakages that
> somehow rather than literally must be addressed by their
> own, if its so breaking the code they should, or us adapt to
> it literally.  
> 
> --- El lun, 18/4/11, Mika Nystrom <mika at async.caltech.edu>
> escribió:
> 
> > De: Mika Nystrom <mika at async.caltech.edu>
> > Asunto: Re: [M3devel] malloc/free from Modula-3?
> > Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > CC: m3devel at elegosoft.com
> > Fecha: lunes, 18 de abril, 2011 14:05
> > "Daniel Alejandro Benavides D."
> > writes:
> > >Hi all:
> > >ok, but are you telling this about in user threads
> or
> > working ill or all th=
> > >reads and pthreads?
> > >Thanks in advance
> > >
> > 
> > I don't know exactly.  There are certainly bad
> > combinations of threading
> > implementations and memory allocators.  And I'm
> sure
> > it may be system
> > dependent as well.  In any case, linking user
> threads
> > with the -pthreads
> > version of libc is probably bad.  Calling malloc
> > willy-nilly from multiple
> > user threads is probably bad.  Calling free, I
> don't
> > know.  Pthreads currently
> > don't work so maybe malloc works there but that
> doesn't
> > help very much if
> > the system is anyhow unstable.
> > 
> >     Mika
> > 
> > >--- El lun, 18/4/11, Mika Nystrom <mika at async.caltech.edu>
> > escribi=F3:
> > >
> > >> De: Mika Nystrom <mika at async.caltech.edu>
> > >> Asunto: Re: [M3devel] malloc/free from
> Modula-3?
> > >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> > >> CC: m3devel at elegosoft.com
> > >> Fecha: lunes, 18 de abril, 2011 13:47
> > >> "Daniel Alejandro Benavides D."
> > >> writes:
> > >> >Hi all:
> > >> >the only thing you need to keep control
> as of
> > CM3 is
> > >> concerned is the modul=3D
> > >> >a-3 free calls equals the number of news,
> that
> > is, if
> > >> not is runtime error,=3D
> > >>=20
> > >> Not exactly.  You can't necessarily
> call
> > malloc/free
> > >> from multiple threads.
> > >> This is a big problem for Modula-3 programs
> that
> > call out
> > >> to nontrivial C code.
> > >>=20
> > >> (Why don't we wrap malloc/free ourselves in
> a
> > special
> > >> library?  Linker problems
> > >> I suppose... and I also suppose the effort
> should
> > rather be
> > >> on getting pthreads
> > >> working again than messing around with
> problems
> > with user
> > >> threads...)
> > >>=20
> > >>      Mika
> > >> 
> >
>