[m-dev.] thread.spawn_native

[Paul Bone]

On Fri, Jun 13, 2014 at 01:23:45PM +1000, Michael Day wrote:
> Hi Paul,
>
> Thinking about it some more, without thread pinning, I don't see the  
> point of having spawn_native at all. Couldn't you just call spawn and  
> use may_not_migrate annotations? And adjust the number of Mercury  
> engines at startup to the desired number?

That was essentially one of my questions to Peter.  One of his requirements
for libxml (or is it libxml2?) was that he needs to garuentee that two
documents are processed on seperate OS threads.  On it's own
may_not_migrate doesn't tell Mercury that two seperate sets of calls to some
foreign code must be done on distinct threads.


> Unless I've got it completely backwards, it seems like the whole point  
> of spawn_native is to give you guaranteed control over a native thread,  
> deliberately breaking the abstraction barrier that would normally be  
> imposed between Mercury code and and the operating system.

I thought it was to solve the problem above.  In addition to this it is very
powerful and may be used for other (arguably good) things that I havn't
thought of.  I find it difficult to decide what parts of a design should
break abstractions such as these because sometimes people have very good
reasons for doing so.  My favorite example is purity and destructive update,
usually purity is great and helps you understand your code more easily, but
at other times it gets in the way of writing fast algorithms such as an
inplace quicksort on an array.

In this case (spawn_native) I wanted to understand the problem Peter was
trying to solve, either to find justification for spawn_native, or find an
alternative solution that met the same requirements.

Thanks.


-- 
Paul Bone