[M3devel] modula-3/pthreads

[Jay]

Tony, does Posix say that? Or testing? Esp. if this behavior is "substandard", should we have GoodPThread.m3 and BadPThread.m3?
And the "attr" is leaked, and perhaps unnecessary?
I'll be running a loop "soon" to see if the attr is leaked, but can't yet.
 
 - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] modula-3/pthreadsDate: Mon, 19 May 2008 07:16:23 -0400


Jay,

Indeed, I originally tried something slightly thinner (see the logs for the gory evolution...) but it only happened to work with Linux threads.  What we have now is about as thin as it can be, given the constraints imposed by the need to schedule thread alerts, etc.  For example, on some systems one cannot reliably wake up a specific thread from among many that are waiting on a condition.  Hence the need for every M3 thread too have its own private condition variable on which it will park itself pending alerts and conditions.


-- Tony

On May 18, 2008, at 2:54 PM, Jay wrote:

Given that pthreads has all of mutex, rwlock, and most importantly condition variables, couldn't ThreadPThread.m3 be very much thinner?Like, not do any of its own scheduling?Also, shouldn;t the attr for stack size be destroyed? Else leak on some platforms? Is it even needed at all? - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080519/66dd0ff4/attachment-0002.html>