[m-rev.] for review: Add thread.spawn_native/4 and thread.spawn/4.

[Paul Bone]

On Fri, Jun 27, 2014 at 02:25:55PM +1000, Peter Wang wrote:
> 
> Here is a followup patch.
> 
> On second thought, I don't know if thread handles themselves should be
> comparable.  I think we should provide a function to get the thread_id
> which can be compared.
> 
>     :- func thread_id(thread) = thread_id.
> 
> Peter
> 
> ---
> 
> Add thread ids to thread handles.
> 
> Thread handles should not be dummy types because all thread handles
> would compare equal.  Add thread ids to thread handles.
> 
> library/thread.m:
>     As above.
>     
>     	Reduce accessibility levels in C# and Java helper classes.
> 

Hi, we're working on the same code so I thought I'd let you know what my
intentions are here WRT threading on Java.

I'm writing some thread pool code for Java that will make tasks (created by
spawn, and in the longer term parallel conjunctions) cheaper.  That is they
will be closures until they begin execution (like sparks).  I have no
problem with implementing spawn_native as a full Java thread and intend to
do this.

I've given each Task a unique id.  Tasks will correspond to the thread type
in thread.m and are normally what is created by spawn.  When the user
uses spawn_native I will still create a Task object, but it will be
converted to a full MercuryThread straight away and the JVM will schedule it
rather than the thread pool.

I don't think that our intentions actually conflict at all, but I thought
I'd let you know now to avoid surprises.

After getting some basic thread pooling implemented I intend to continue my
work on parallel profiling (formerly ThreadScope) and implement this for the
Java backend as well as fixing it for the low-level C backend.


Thanks.


-- 
Paul Bone