[m-dev.] thread.spawn_native

[Michael Day]

Hi Paul,

> If this isn't combined with a method of pinning the context to the engine,
> and specifying that any foreign calls made within parallel conjunctions are
> also executed on the same context (all implementation details) then it won't
> work.  Which is what may_not_migrate is intended to solve.

Okay, I guess I was thinking that if you called spawn_native, and the 
Mercury code later blocked, then the whole thread would just block, 
instead of scheduling a different Mercury context to run on it. Also, 
that parallel conjunctions would be disabled for this thread. As a 
result, it would give a guarantee that the code has complete ownership 
of the thread and will not be preempted by some other unrelated code. 
Thus no annotations on the foreign procs would be necessary.

Does that sound too low-level, or just too incompatible with the way 
Mercury engines and contexts work?

Alternatively, it would be nice to hear a description of the proposed 
may_not_migrate annotation that could be understood by a programmer with 
no understanding of Mercury implementation details :)

> In option #2 and because glVertex doesn't block so we can ignore
> asynchronous IO.  there is no need to switch threads all the time.  If the
> context is on the wrong thread then it is switched to the correct one before
> calling glVertex and remains there until there's a different reason to
> switch it again (maybe it goes to sleep and wakes up elsewhere?).  These
> context switches should be rare but will be able to be measured.

Right, so in this case "on the wrong thread" means not on the thread for 
which the Mercury engine was originally created, because they've 
switched at some point as a side-effect of other synchronisation 
primitives? Seems like an indirect way of achieving thread-pinning, 
similarly to trying to tie a process to a specific CPU. I was hoping 
that spawn_native would give that by default.

Cheers,

Michael

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