[M3devel] modula-3/pthreads

[Tony Hosking]

POSIX is *very* liberal in what behaviors it allows.  I don't think it  
makes any sense to further divide thread subsystems into good/bad  
based on behaviors that are undefined by the SPEC.

On May 19, 2008, at 8:04 AM, Jay wrote:

> 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.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] modula-3/pthreads
> Date: 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/d6a7b44d/attachment-0002.html>