[M3devel] (no subject)

[Tony Hosking]

Jay,

Before you go off half cocked and brew up some new threads system  
might I suggest that it would be better to find and fix the current  
problem.  I am sceptical that there is a much thinner M3 thread  
implementation on top of pthreads than we currently have.  I am in the  
process of tracking down the problem on I386_DARWIN (I see at least  
one thing broken right now, and will have a fix soon).

In answer to your question, the wait list is to deal with M3 alerts,  
which are not the same as pthread cancellation.

Antony Hosking | Associate Professor | Computer Science | Purdue  
University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On 7 Sep 2009, at 05:33, Jay K wrote:

> Tony, can you..um, trick question sort of, briefly explain the  
> differences between pthreads and Modula-3 threads?
> The "trick" part is that, to an audience (me) who is not all that  
> familiar with the nuances of either?
> I'll see if I can find my green book and other reference material  
> (online).
>
>
> I understand the basics of threading very well, if that helps.
> Eh, not much to it really.
>
>
> I'm not super familiar with condition variables, as Win32 didn't  
> historically have them.
> But I think I understand them.
>
>
> Specific questions:
>   Can Modula-3 threads be implemented more directly upon pthreads?
>
>
>   Why do we need to maintain a waiting list?
>
>
>   Is "alert" the same as "cancel" in pthread vocabulary? Or almost  
> the same?
>
>
>   I understand..there might be a difficult problem..does Modula-3  
> allow catching an alert? I think so.
>   Does Posix allow canceling a cancel? I think not.
>
>
>   Posix allows, what I think of as try/finally, for alert. Modula-3  
> probably does too. Even though you can't stop the cancel, you can  
> run "cleanup" code that runs before the cancel completes.
>
>
> However mapping Modula-3 to Posix here would be tricky. As I see  
> things..any function with a try/finally would have to be contorted  
> into a form that passes a pointer to itself, along with parameters,  
> to C code that does pthread_cleanup_push/pop around calling the  
> function pointer. At least given the Darwin implementation. Other  
> implementations might simply be able to call push at the start and  
> pop at the end. But on Darwin these functions are macros where push  
> introduces a local variable that pop references. I guess maybe one  
> could to the "reverse engineering" approach (just by reading the  
> header). But it'd still be ugly.
>
>
> I have to do more research here.
>
>
> I'm seriously consider "writing" a ThreadPThreadDirect.m3 that is  
> thinner than the current ThreadPThread.m3 and see how it fairs,  
> specifically if the Juno hangs go away.
> "writing" being an exaggeration because it should be very small.
>
>
> Thanks,
>  - Jay
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090907/d904c02d/attachment-0002.html>