<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
"Green" threads are probably another name for user threads. Java used to use something with this name.<BR>
<BR>
> Also, in the current CM3 HEAD implementation, are we still using Windows native threads on WIN32 platforms?<BR><BR>
Certainly. Has anything ever given you a different impression?<BR>
<BR>
Cygwin maybe uses pthreads, but that'd still use Win32 threads under the covers.<BR>
<BR>
It *might* be nice to have a user thread option that used fibers or Win7's UMS (64-bit only!) but don't hold your breath.<BR>
Native Win32 threads have been around forever and will be a good option forever and will be in heavy use forever.<BR>
<BR>
- Jay <BR> <BR>
> From: rcolebur@SCIRES.COM<BR>> To: m3devel@elegosoft.com<BR>> Date: Mon, 18 Apr 2011 17:35:40 -0400<BR>> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4<BR>> <BR>> I think it would be good at this point to clarify for folks on the m3devel list what is meant by the various terms:<BR>> -pthreads<BR>> -user threads<BR>> -Win32 native threads<BR>> -green threads<BR>> -etc.<BR>> <BR>> I think I know what all these mean, except for "green" threads, but I'm not quite sure anymore.<BR>> <BR>> Also, in the current CM3 HEAD implementation, are we still using Windows native threads on WIN32 platforms?<BR>> <BR>> 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.<BR>> <BR>> 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.<BR>> <BR>> Regards,<BR>> Randy Coleburn<BR>> <BR>> -----Original Message-----<BR>> From: Mika Nystrom [mailto:mika@async.caltech.edu] <BR>> Sent: Monday, April 18, 2011 2:46 PM<BR>> To: Tony Hosking<BR>> Cc: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] 5.8.6 LINUXLIBC6 breakage, kernel 2.6.23, glibc-2.6-4<BR>> <BR>> Tony Hosking writes:<BR>> ...<BR>> >pthread_atfork should not be needed under user threads.<BR>> ...<BR>> <BR>> The following code from RTProcessC.c ensures that it is neeeded on every Unix except<BR>> FreeBSD before 6. The comment is from the checked-in source file.<BR>> <BR>> /* NOTE: Even userthreads now depends<BR>> * on availability of pthreads.<BR>> * This can be fixed if need be.<BR>> */<BR>> <BR>> INTEGER<BR>> __cdecl<BR>> RTProcess__RegisterForkHandlers(<BR>> ForkHandler prepare,<BR>> ForkHandler parent,<BR>> ForkHandler child)<BR>> {<BR>> /* FreeBSD < 6 lacks pthread_atfork. Would be good to use autoconf.<BR>> * VMS lacks pthread_atfork? Would be good to use autoconf.<BR>> * Win32 lacks pthread_atfork and fork. OK.<BR>> *<BR>> * As well, for all Posix systems, we could implement<BR>> * atfork ourselves, as long as we provide a fork()<BR>> * wrapper that code uses.<BR>> */<BR>> #if defined(_WIN32) \<BR>> || defined(__vms) \<BR>> || (defined(__FreeBSD__) /* && (__FreeBSD__ < 6)*/ )<BR>> return 0;<BR>> #else<BR>> while (1)<BR>> {<BR>> int i = pthread_atfork(prepare, parent, child);<BR>> if (i != EAGAIN)<BR>> return i;<BR>> sleep(0);<BR>> }<BR>> #endif<BR>> }<BR>> <BR> </body>
</html>