[M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4

[Daniel Alejandro Benavides D.]

Hi all:
I think if each thread handle is RT specific form then you need to be aware of that before wanting to change system and platform, rather than of implementation, so each specific module procedure must be not UNSAFE but  platform ready for its available platforms, now if something is specified implementation dependent must have a CM3 suffix for that purpose so everybody keeps and eye on its implementation aspects, so each RTThreadCM3.i3 is clearer to group as they are intended to serve as are RTCollectorSRC.i3 to RTCollector.i3 to mean is not specific to CM3 so to have implementations e.g SOLsun user threads, LINUXLIBC6 x86 user threads (implemented for Multimedia Modula-3, called MM3, etc) but anything else like for unique for Windows, SPIN, is like normal like RTException.i3 and if something is supported just for DEC Unix for instance, then it is better to say RTExceptionOSF.i3 etc in that way if so and not CM3 or anything else.
Thanks in advance
 

--- El lun, 18/4/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribió:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4
> Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: lunes, 18 de abril, 2011 16:35
> I think it would be good at this
> point to clarify for folks on the m3devel list what is meant
> by the various terms:
> -pthreads
> -user threads
> -Win32 native threads
> -green threads
> -etc.
> 
> I think I know what all these mean, except for "green"
> threads, but I'm not quite sure anymore.
> 
> Also, in the current CM3 HEAD implementation, are we still
> using Windows native threads on WIN32 platforms?
> 
> I too am observing problems with threading on Windows not
> behaving well.  This situation concerns me because
> thread safety is something I've always relied on Modula-3 to
> provide.
> 
> I think we need to post how the various threading models
> map to the various implementation platforms, and what
> options one needs to use to select between the models, and
> on which platforms a choice of threading model is
> available.
> 
> Regards,
> Randy Coleburn
> 
> -----Original Message-----
> From: Mika Nystrom [mailto:mika at async.caltech.edu]
> 
> Sent: Monday, April 18, 2011 2:46 PM
> To: Tony Hosking
> Cc: m3devel at elegosoft.com
> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel
> 2.6.23, glibc-2.6-4
> 
> Tony Hosking writes:
> ...
> >pthread_atfork should not be needed under user
> threads.
> ...
> 
> The following code from RTProcessC.c ensures that it is
> neeeded on every Unix except
> FreeBSD before 6.  The comment is from the checked-in
> source file.
> 
> /* NOTE: Even userthreads now depends
>  * on availability of pthreads.
>  * This can be fixed if need be.
>  */
> 
> INTEGER
> __cdecl
> RTProcess__RegisterForkHandlers(
>     ForkHandler prepare,
>     ForkHandler parent,
>     ForkHandler child)
> {
> /* FreeBSD < 6 lacks pthread_atfork. Would be good to
> use autoconf.
>  * VMS lacks pthread_atfork? Would be good to use
> autoconf.
>  * Win32 lacks pthread_atfork and fork. OK.
>  *
>  * As well, for all Posix systems, we could implement
>  * atfork ourselves, as long as we provide a fork()
>  * wrapper that code uses.
>  */
> #if defined(_WIN32) \
>         || defined(__vms) \
>         || (defined(__FreeBSD__) /*
> && (__FreeBSD__ < 6)*/ )
>     return 0;
> #else
>     while (1)
>     {
>       int i = pthread_atfork(prepare,
> parent, child);
>       if (i != EAGAIN)
>         return i;
>       sleep(0);
>     }
> #endif
> }
> 
>