[m-dev.] thread.spawn_native

[Michael Day]

>> Right.  However, if such a call occurs within a parallel conjunction
>> then it could be performed on one of the parallel worker threads
>> instead.  I can't think of a situation where you'd write that code
>> deliberately.
>
> Deliberate or not this affects software composability, so we need to make it
> safe.

So for foreign APIs that require being called on the same thread, there 
will be two (or three?) ways to make them work in Mercury:

1) Manage your own threads by calling spawn_native and only calling the 
foreign API from that thread.

2) Let the compiler manage the threads by putting may_not_migrate 
annotations on the foreign procs.

3) Something to do with IO worker threads, so when you call a foreign 
proc it transparently switches to an IO worker thread and calls it from 
there instead?

I like option #1 the best :)

I don't see how option #2 will work. If a naive wrapping of legacy 
OpenGL made each function a foreign proc, then would each call to 
glVertex potentially need to switch threads? Wouldn't there be a lot of 
overhead? And doesn't option #3 suffer from this as well?

Michael

-- 
Prince: Print with CSS!
http://www.princexml.com