[m-dev.] thread.spawn_native

[Julien Fischer]

On Fri, 6 Jun 2014, Paul Bone wrote:

> On Fri, Jun 06, 2014 at 02:03:32PM +1000, Peter Wang wrote:

...

>> As a related proposal, we may add a thread handle type and thread.join
>> so that the user can be certain when a thread is terminated and its
>> resources cleaned up.
>>
>> :- type thread.
>>
>> :- pred thread.spawn_native(
>>     pred(thread, io, io)::in(pred(in, di, uo) is cc_multi),
>>     maybe_error(thread)::out, io::di, io::uo) is cc_multi.
>>
>> :- pred thread.join(thread::in, io::di, io::uo) is det.
>>
>> I am not sure whether thread.join should be mandatory to call.
>>
>> The thread handle would give us a convenient place to hang a thread
>> identifier, useful for logging and debugging.

Agreed in principle.  It's more or less obvious what should happen here
in the hlc.par.gc and non-C grades here, but for the low-level C grades
what happens here?  What does the thread handle correspond to?

>> The thread handle could have a slot to hold a return value for
>> thread.join.  Not strictly necessary.
>
> I like this idea.
>
> I also think that thread.join could be made mandatory per-thread.  For
> example, Java has the concept of normal threads and deamon threads.  To
> clean up a normal thread you must call join, but this is not necessary for a
> deamon thread.  Also the process will only exit once there are zero normal
> threads running, but any number of deamon threads may be active when the
> process ends (but we don't need that behaviour (I think)).
>
> In the interim the new barrier library could be used to know when a thread
> exists.  If you want a thread to return a result as it exits I suggest using
> a channel (in the interim).
>
> Hrm, if we introduce join, we should also consider its behavour if a thread
> throws an exception to its top level.

That behaviour needs to be considered regardless of whether join is
introduced or not.

Cheers,
Julien.