[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.
Julien Fischer
jfischer at opturion.com
Fri Jun 27 16:52:36 AEST 2014
On Fri, 27 Jun 2014, Julien Fischer wrote:
>
> On Fri, 27 Jun 2014, Paul Bone wrote:
>
>> On Fri, Jun 27, 2014 at 03:47:07PM +1000, Julien Fischer wrote:
>>>>
>>>> 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.
>>>
>>
>> I agree, at least until we have a need to sepearate them, for example if
>> Peter wants to store the result of a thread's execution inside the thread
>> type.
>
> Even then, why do you need to make a separate thread_id type visible to
> the user? Thread handles could be defined as follows:
>
> :- type thread
> ---> thread_handle(
> thread_id :: <<target specific thread id>>,
> thread_state :: <<ref to some heap cell>>
> etc etc.
> ).
>
> Comparison and unification of thread handles would be done using the
> first field of the above structure (i.e. what happens by default.)
Obviously, that is *not* what happens by default! It's Friday afternoon
...
Cheers,
Julien.
More information about the reviews
mailing list