[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.

[Julien Fischer]

On Fri, 27 Jun 2014, Peter Wang wrote:

> On Fri, 27 Jun 2014 11:54:00 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi Peter,
>>
>> On Wed, 25 Jun 2014, Peter Wang wrote:
>>
>>> -%-----------------------------------------------------------------------------%
>>> -
>>> :- implementation.
>>>
>>> +:- import_module bool.
>>> +:- import_module require.
>>> +:- import_module string.
>>> +
>>> :- pragma foreign_decl("C", "
>>> #ifndef MR_HIGHLEVEL_CODE
>>>   #if (!defined(MR_EXEC_TRACE) && !defined(MR_DEEP_PROFILING)) || !defined(MR_USE_GCC_NONLOCAL_GOTOS)
>>> @@ -91,32 +122,54 @@
>>> #endif
>>> ").
>>>
>>> +    % Nothing yet but it can be used to hold a thread id, joining, holding
>>> +    % uncaught exception values, etc.
>>> +:- type thread
>>> +    --->    thread.
>>
>> Using a dummy type as the definition for thread handles means that all
>> thread handles will unify and compare as equal.  (Which surely shouldn't
>> be the case if the originate from different calls to spawn.)
>
> Here is a followup patch.
>
> On second thought, I don't know if thread handles themselves should be
> comparable.  I think we should provide a function to get the thread_id
> which can be compared.
>
>    :- func thread_id(thread) = thread_id.
>
> Peter
>
> ---
>
> Add thread ids to thread handles.
>
> Thread handles should not be dummy types because all thread handles
> would compare equal.  Add thread ids to thread handles.

Is there any reason the thread handles and thread ids cannot be the
same thing at the user level?  I don't see why we require a separate
thread_id type.

Cheers,
Julien.