[M3devel] Downsides of Modula-3 ?

[Daniel Alejandro Benavides D.]

Hi all:
Please this makes think that the current systems are a lottery, because they don't mark thread-safe code (or they are all safe assumed as thread-unsafe):
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 are thread-unsafe is correct to say.
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:30
> 
> 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.
> 
>     Mika
> 
> "Daniel Alejandro Benavides D." writes:
> >Hi all:
> >I'm more suspicious about the back needs over this
> programs, since Win32 pr=
> >ograms have worked OK, have they? So I agree with you
> it's a matter of targ=
> >et 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 te=
> >sts are OK either pthreads or embedded M3 threads this
> is a clear symptom o=
> >f that UP semantics issue.
> >In any case don't expect too many threads to do that
> correctly, since any e=
> >xception in them can't be managed by Modula-3 RT (by
> language definition) b=
> >ut 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=E1b, 21/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: "Jay K" <jay.krell at cornell.edu>
> >> CC: m3devel at elegosoft.com
> >> Fecha: s=E1bado, 21 de abril, 2012 18:36
> >> Jay K writes:
> >> >1) please elaborate=20
> >>=20
> >> >2) We don't use longjmp as much any more=3D2C
> but
> >> get/set=3D
> >> >/make/swapcontext on platforms that support
> them.And
> >> where we do use longjm=3D
> >> >p=3D2C we have a more portable use than before
> -- we no
> >> longer hack on the jm=3D
> >> >pbuf.There is a "trick" where you use
> sigsetstack or
> >> some such to get the s=3D
> >> >tack pointer into the jmpbuf.Look at the code
> and read
> >> the paper referenced=3D
> >> >. It is possible it didn't work on all
> platforms.=20
> >> But anyway=3D2C see #1.We'=3D
> >> >d really prefer to just use pthreads.Hm. I'd
> like to
> >> look again at what pth=3D
> >> >reads features we use -- I suspect
> pthreads/Win32 can
> >> beabstracted more thi=3D
> >> >nly and the Modula-3 code
> less-forked/more-shared. But
> >> later..  - Jay > Fro=3D
> >>=20
> >> Sorry for the bad quote.  My mailer still
> lives in the
> >> 7-bit world.
> >>=20
> >> 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...
> >>=20
> >> 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.
> >>=20
> >>      Mika
> >> 
>