[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?


More information about the reviews mailing list