[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.
Julien Fischer
jfischer at opturion.com
Fri Jun 27 17:36:13 AEST 2014
On Fri, 27 Jun 2014, Peter Wang wrote:
> On Fri, 27 Jun 2014 16:52:36 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>>
>>> 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
>> ...
>
> Yeah, okay, either the first fields are not equal, or the top-level
> addresses are equal, so therefore the later fields are never considered.
>
> I'd still be more comfortable with map(thread_id, T) where thread_id
> values are plain Mercury terms
So similar to what we do for file streams then?
Julien.
More information about the reviews
mailing list