<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 5:41 PM, Paul Bone <span dir="ltr"><<a href="mailto:paul@bone.id.au" target="_blank">paul@bone.id.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Fri, Jun 27, 2014 at 04:49:57PM +1000, Julien Fischer wrote:<br>
><br>
> Even then, why do you need to make a separate thread_id type visible to<br>
> the user?   Thread handles could be defined as follows:<br>
><br>
>     :- type thread<br>
>       --->    thread_handle(<br>
>                   thread_id    :: <<target specific thread id>>,<br>
>                     thread_state :: <<ref to some heap cell>><br>
>                     etc etc.<br>
>                  ).<br>
<br>
</div>Wouldn't this typically be a foreign type?  It makes no difference to the<br>
user since it's opaque and it would be the natural way to implement it for<br>
any given backend.<br></blockquote><div><br></div><div>If the majority of the code accessing the thread handle is Mercury code</div><div>it would make more sense for it to be Mercury and vice versa.  We can't</div><div>
decide that until there is actually some functionality that uses thread handles.</div><div><br></div><div>Certainly, the underlying thread_id (i.e. the first field above) would need to</div><div>be a foreign_type. </div><div>
<br></div><div>Cheers,</div><div>Julien.</div></div><br></div></div>