[M3devel] join twice?

[Tony Hosking]

So, here is a question.  What happens with AlertJoin?  If I get an  
alert before the join occurs can I rejoin?  It would seem reasonable  
that I should be able to do so.

Should we simply permit only one joiner at any given time?

On 3 Nov 2009, at 10:16, Tony Hosking wrote:

> The original threads spec for Modula-3 does not mention join can  
> only run once.  The only mention is in Thread.i3.
>
> I agree that it seems silly to join twice.  On the other hand, Java  
> semantics does not prohibit multiple joins.
>
> 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 3 Nov 2009, at 10:04, Jay K wrote:
>
>>
>> To me..with a Win32 background..join means "wait for thread to  
>> finish".
>>
>> And there is a separate action "get thread result".
>>
>> You could consider these one merged operation "wait for thread to  
>> finish and get its result".
>>
>> In either case, it is reasonable to allow it multiple times.
>>
>> Waiting for a thread to finish that has already finished is just  
>> fast.
>>
>> Getting a thread result that you already got is also easy albeit  
>> usually unnecessary.
>>
>>
>>
>> Now, if the operation is "wait for thread to finish, get its  
>> result, and lose track of its result",
>>
>> that isn't idempotent.
>>
>>
>>
>> I'm torn. The existing implementations all either support multiple  
>> join or have to go out of
>>
>> their way to prevent it. Yet Thread.i3 has been commented so  
>> presumably forever.
>>
>>
>>
>> - Jay
>>
>>
>>
>>
>> Date: Tue, 3 Nov 2009 09:36:23 -0500
>> From: rcoleburn at scires.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] join twice?
>>
>>
>> I think the comment in the code is correct.
>>
>> Semantically, it doesn't make sense to join a thread more than  
>> once.  Join is the compliment to Fork.  With fork, one thread  
>> becomes two.  With Join, two threads become one.  After they've  
>> become one, the 2nd thread is no more, so you can't join to it  
>> anymore.
>>
>> IMO, the implementation should enforce this behavior.  What would  
>> be the "benefit" of allowing more than one join?  What does it  
>> "mean" to join a "dead thread"?
>>
>> Regards,
>> Randy Coleburn
>>
>>>>> Tony Hosking <hosking at cs.purdue.edu> 11/2/2009 11:54 PM >>>
>>
>>
>>
>>
>> OK, sure.  Fair enough.
>>
>>
>> On 2 Nov 2009, at 16:43, Jay K wrote:
>>
>>> (Whether the implementation actually prohibits it or not is an  
>>> implementation decision.)
>>
>> Tony, I'm sympathetic to the smaller version but I think it is wrong.
>> "It is a checked runtime error to call this more than once for any t"
>> is a much different/stronger statement than e.g.
>> "it is implementation defined what happens if you call join more  
>> than once for any t".
>> The printed Reactor 4.1 docs have the same comment as current  
>> Thread.i3.
>>
>> You know, ideally if I write:
>> Thread.Join(t);
>> Thread.Join(t);
>>
>> and it works today on any system, it will continue to work on all  
>> systems
>

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