[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.
jfischer at opturion.com
Fri Jun 27 16:49:57 AEST 2014
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.
>>> 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
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_id :: <<target specific thread id>>,
thread_state :: <<ref to some heap cell>>
Comparison and unification of thread handles would be done using the
first field of the above structure (i.e. what happens by default.)
More information about the reviews