[M3devel] Downsides of Modula-3 ?

Sun Apr 22 20:01:21 CEST 2012

Hi all:
I agree too, but then that is assuming that you code is inherently thread-safe, which we don't care either or worse in Modula-e libraries BTW, we could have THREADSAFE or SAFE keyword of that and so ...
Now, what Antony and someone once said, that "embedded" green threads are not that semantically correct assuming some things over them (for instance UP semantics), then we should make some primitives for handling the new implementation of threads just to be sure. 
Thanks in advance

--- El dom, 22/4/12, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: m3devel at elegosoft.com
> Fecha: domingo, 22 de abril, 2012 12:43
> 
> But the thing is, if the produced code were thread unsafe,
> it likely
> wouldn't work with user threads either...
> 
> I admit what you say is possible but it ought to be ruled
> out by the
> semantics of pthreads.  
> 
>     Mika
> 
> "Daniel Alejandro Benavides D." writes:
> >Hi all:
> >Please this makes think that the current systems are a
> lottery, because the=
> >y don't mark thread-safe code (or they are all safe
> assumed as thread-unsaf=
> >e):
> >http://h71000.www7.hp.com/doc/72final/6493/6101pro_008.html#making_safe
> >
> >Even if they compiler is not threaded by itself it can
> cause a back-end to =
> >be thread-unsafe, so that's why I say that it could be
> in that back-end.
> >
> >But then the code must be marked by each module and I
> think assuming all ar=
> >e thread-unsafe is correct to say.
> >Thanks in advance
> >
> >--- El dom, 22/4/12, Mika Nystrom <mika at async.caltech.edu>
> escribi=F3:
> >
> >> De: Mika Nystrom <mika at async.caltech.edu>
> >> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> >> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> >> CC: m3devel at elegosoft.com
> >> Fecha: domingo, 22 de abril, 2012 12:30
> >>=20
> >> I'm almost certain the problem is somewhere in the
> pthreads
> >> implementation
> >> of M3 threads, which consists of a couple of files
> of C and
> >> M3 within
> >> m3core.
> >>=20
> >>     Mika
> >>=20
> >> "Daniel Alejandro Benavides D." writes:
> >> >Hi all:
> >> >I'm more suspicious about the back needs over
> this
> >> programs, since Win32 pr=3D
> >> >ograms have worked OK, have they? So I agree
> with you
> >> it's a matter of targ=3D
> >> >et implementation (not UNSAFE world), but
> that's in
> >> m3gcc backend, isn't it=3D
> >> >?
> >> >Similarly your code could be fixed to
> uniprocessor
> >> semantics, so if this te=3D
> >> >sts are OK either pthreads or embedded M3
> threads this
> >> is a clear symptom o=3D
> >> >f that UP semantics issue.
> >> >In any case don't expect too many threads to do
> that
> >> correctly, since any e=3D
> >> >xception in them can't be managed by Modula-3
> RT (by
> >> language definition) b=3D
> >> >ut at most in m3gcc semantics I believe so.
> DECthreads
> >> had a nice mechanism=3D
> >> > to wrap it to Modula-3 style semantics so it
> could be
> >> easier to offer that=3D
> >> > in a internal CM3 API.
> >> >Thanks in advance
> >> >
> >> >
> >> >--- El s=3DE1b, 21/4/12, Mika Nystrom <mika at async.caltech.edu>
> >> escribi=3DF3:
> >> >
> >> >> De: Mika Nystrom <mika at async.caltech.edu>
> >> >> Asunto: Re: [M3devel] Downsides of
> Modula-3 ?
> >> >> Para: "Jay K" <jay.krell at cornell.edu>
> >> >> CC: m3devel at elegosoft.com
> >> >> Fecha: s=3DE1bado, 21 de abril, 2012
> 18:36
> >> >> Jay K writes:
> >> >> >1) please elaborate=3D20
> >> >>=3D20
> >> >> >2) We don't use longjmp as much any
> more=3D3D2C
> >> but
> >> >> get/set=3D3D
> >> >> >/make/swapcontext on platforms that
> support
> >> them.And
> >> >> where we do use longjm=3D3D
> >> >> >p=3D3D2C we have a more portable use
> than before
> >> -- we no
> >> >> longer hack on the jm=3D3D
> >> >> >pbuf.There is a "trick" where you use
> >> sigsetstack or
> >> >> some such to get the s=3D3D
> >> >> >tack pointer into the jmpbuf.Look at
> the code
> >> and read
> >> >> the paper referenced=3D3D
> >> >> >. It is possible it didn't work on
> all
> >> platforms.=3D20
> >> >> But anyway=3D3D2C see #1.We'=3D3D
> >> >> >d really prefer to just use
> pthreads.Hm. I'd
> >> like to
> >> >> look again at what pth=3D3D
> >> >> >reads features we use -- I suspect
> >> pthreads/Win32 can
> >> >> beabstracted more thi=3D3D
> >> >> >nly and the Modula-3 code
> >> less-forked/more-shared. But
> >> >> later..  - Jay > Fro=3D3D
> >> >>=3D20
> >> >> Sorry for the bad quote.  My mailer
> still
> >> lives in the
> >> >> 7-bit world.
> >> >>=3D20
> >> >> In any case I was just mentioning as a
> problem with
> >> the
> >> >> current Modula-3
> >> >> implementation that the pthreads bindings
> are
> >> buggy.  I
> >> >> would not (and
> >> >> do not) use them for serious work. 
> And user
> >> threads
> >> >> are, as we all know,
> >> >> not ideal...
> >> >>=3D20
> >> >> Anybody who wants to investigate the
> matter can
> >> start by
> >> >> running the thread
> >> >> testing program in m3core/tests/thread
> ...=20
> >> Main.m3 is
> >> >> fairly well documented.
> >> >>=3D20
> >> >>      Mika
> >> >>=20
> >> 
> 