[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