[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.

Julien Fischer jfischer at opturion.com
Fri Jun 27 17:45:58 AEST 2014


On Fri, Jun 27, 2014 at 5:41 PM, Paul Bone <paul at bone.id.au> wrote:

> On Fri, Jun 27, 2014 at 04:49:57PM +1000, Julien Fischer 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.
> >                  ).
>
> Wouldn't this typically be a foreign type?  It makes no difference to the
> user since it's opaque and it would be the natural way to implement it for
> any given backend.
>

If the majority of the code accessing the thread handle is Mercury code
it would make more sense for it to be Mercury and vice versa.  We can't
decide that until there is actually some functionality that uses thread
handles.

Certainly, the underlying thread_id (i.e. the first field above) would need
to
be a foreign_type.

Cheers,
Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20140627/3b222a90/attachment.html>


More information about the reviews mailing list