[m-dev.] thread.spawn_native

[Peter Wang]

On Wed, 11 Jun 2014 09:44:34 +1000, Paul Bone <paul at bone.id.au> wrote:
> On Tue, Jun 10, 2014 at 06:09:06PM +1000, Peter Wang wrote:
> > 
> > What happens for a may_not_migrate, may_call_mercury foreign proc?
> > Presumably the foreign code in the IO worker will need to arrange
> > for the Mercury proc to be executed by one of the fixed number Mercury
> > engines, and wait for the result.  If the Mercury proc calls
> > another `may_not_migrate' foreign proc, it deadlocks?
> 
> Urgh.  This is getting messy.
> 
> Yeah, I'd say that the Mercury engine would have to execute the Mercury
> code, and the IO worker may have to wait around without executing any other
> C code.  Effectivly, it's not an IO worker anymore but a slave to that
> particular Mercury context's foreign calls.
> 
> Another "solution" is to make may_not_migrate and may_call_mercury
> incompatible.
> 
> > > Yes, my intention is that multiple contexts could be bound to the same
> > > Mercury engine.  I beleive the managment of a thread-local state that's used
> > > by foreign code is the responsability of the foreign code.  Mercury cannot
> > > protect some foreign code from stepping on some other foreign code's state.
> > 
> > That severely reduces the value of a may_not_migrate annotation.
> > I don't know how you could practically use any API that depends on
> > OS-thread-state then, except one thread at a time.
> 
> I'm worried that we don't understand each other's meaning.  Lets say that we
> have two C libraries,  liba and libb.  Both use thread local storage and
> once initialised, must always be called by the same pthread (without extra
> work/reinitialisation).  However, each library's thread local storage is
> handled correctly so a won't clobber b and b won't clobber a (if they did
> then thay'd be terrible and would probably clobber Mercury's state too).
> 
> I see may_not_migrate as a solution to this problem, once a call is made to
> liba then all following calls to liba are made by the same OS thread.  Ditto
> for b.  But this still allows a thread to call a, then b, then a again, or
> whatever (which is necessary EG in a non-parallel context/grade).
> 
> I don't see how allowing an OS thread to call either library creates a
> problem, which seems to be what you're saying.

The problem is when two Mercury contexts try to use the same library
simultaneously.  They cannot rely on thread-local state to persist
across calls:

    1. context-1 calls liba.set(1) -- performed on IO-thread-1
    2. context-2 calls liba.set(2) -- also performed on IO-thread-1
    3. context-1 calls liba.get -- performed on IO-thread-1

Peter