[M3devel] Downsides of Modula-3 ?

[Daniel Alejandro Benavides D.]

Hi all:
Have you read this, if the answer is not, maybe you should, because it seems, this person knows that from the beginning there were problems in the language specification in thread semantics.
https://groups.google.com/group/comp.arch/msg/880a211df40506ab?hl=en

Rodney (and Mika), please make sure your code (implementation) is OK with standard semantics likewise I will do try to accept the Modula-3 semantics of threads are OK, hum, this could be fun, but, very hard, even Larch/Modula-3 might not be able to correct every error on it (so then I might say that is correct and safe, but anything SAFE). Of course there will always room running in circles but still is better to check if something else can be done properly, I mean, that you can't be safe-threaded for %100, can you? That's maybe why they drop the word SAFE for Modula-3 and that's good, they are honest.
Thanks in advance



--- El dom, 22/4/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> Para: m3devel at elegosoft.com
> Fecha: domingo, 22 de abril, 2012 13:43
> 
> 
> On 04/22/2012 11:41 AM, Daniel Alejandro Benavides D.
> wrote:
> > Hi all:
> > I'm more suspicious about the back needs over this
> programs, since Win32 programs have worked OK, have they? So
> I agree with you it's a matter of target implementation (not
> UNSAFE world), but that's in m3gcc backend, isn't it?
> > Similarly your code could be fixed to uniprocessor
> semantics, so if this tests are OK either pthreads or
> embedded M3 threads this is a clear symptom of that UP
> semantics issue.
> > In any case don't expect too many threads to do that
> correctly, since any exception in them can't be managed by
> Modula-3 RT
> (by language definition)
> 
> I'm not sure what you mean by this, but in my reading, the
> language definition fully defines the interaction
> between threads and exceptions.  Exceptions can
> propagate only within a thread.  All the rules about
> where
> they propagate are in terms of either a statically enclosing
> block or a dynamic parent, that is, the caller
> of the current procedure.  In both cases, it's strictly
> within the thread where the exception was raised.
> 
> If an exception ever got to the top of the call chain of its
> thread, it would have to be the result of an
> override of the apply method of the closure passed to
> Thread.Fork.  But that method has an empty RAISES
> clause, so if that should happen, it would be a runtime
> error, still within the thread.
> 
> but at most in m3gcc semantics I believe so. DECthreads had
> a nice mechanism to wrap it to Modula-3 style semantics
> so it could be easier to offer that in a internal CM3 API.
> > Thanks in advance
> >
> >
> > --- El sáb, 21/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: "Jay K"<jay.krell at cornell.edu>
> >> CC: m3devel at elegosoft.com
> >> Fecha: sábado, 21 de abril, 2012 18:36
> >> Jay K writes:
> >>> 1) please elaborate
> >>
> >>> 2) We don't use longjmp as much any more=2C
> but
> >> get/set=
> >>> /make/swapcontext on platforms that support
> them.And
> >> where we do use longjm=
> >>> p=2C we have a more portable use than before --
> we no
> >> longer hack on the jm=
> >>> pbuf.There is a "trick" where you use
> sigsetstack or
> >> some such to get the s=
> >>> tack pointer into the jmpbuf.Look at the code
> and read
> >> the paper referenced=
> >>> . It is possible it didn't work on all
> platforms.
> >> But anyway=2C see #1.We'=
> >>> d really prefer to just use pthreads.Hm. I'd
> like to
> >> look again at what pth=
> >>> reads features we use -- I suspect
> pthreads/Win32 can
> >> beabstracted more thi=
> >>> nly and the Modula-3 code
> less-forked/more-shared. But
> >> later..  - Jay>  Fro=
> >>
> >> Sorry for the bad quote.  My mailer still
> lives in the
> >> 7-bit world.
> >>
> >> 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...
> >>
> >> Anybody who wants to investigate the matter can
> start by
> >> running the thread
> >> testing program in m3core/tests/thread ... 
> Main.m3 is
> >> fairly well documented.
> >>
> >>       Mika
> >>
> >
>