[M3devel] Downsides of Modula-3 ?

[Rodney M. Bates]

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
>>
>