[MLton] More on parallelism

[Matthew Fluet]

> On Dec 4, 2006, at 9:41 PM, Matthew Fluet wrote:
>> 2) Rework the MLton.Thread implementation to make use of multiple OS-level
>>    threads.  It is likely that the right framework here is that a runtime
>>    option indicates the total number of OS-level threads that one wants,
>>    which will be multiplexed among an arbitary number of MLton.Thread's.
>
> Please don't do this.
> I think people would want two different Thread interfaces; one for "OS" 
> threads and one for the kind that exist now.

Can you justify this choice?  I don't have a lot of intuition here.  I'll 
note that in GHC, there is only one Haskell notion of thread (spawned by 
forkIO), which is shared by a variety of runtime implementations: single 
OS-threaded and multiple OS-threaded.  For multiple OS threads, you 
indicate the number of OS-threads that you want via a runtime system 
parameter.

>>    Alternatively, one could design a MLton.PThread structure that exposes
>>    the OS-Level threads.  Here, one would be able to start a new PThread
>>    and initialize it with the ML thread of control.  This ML thread of
>>    control could set up the signal handler (for preemptive ML threads) and
>>    then start pulling ML threads off the shared queue.
>
> Sounds much better.

The downside of making it entirely dynamic on the ML side is that the 
runtime system can't allocate a single array for all of the possible 
OS-level threads.

A compromise would be a runtime option that indicates the maximum number 
of OS level threads to allow (so we can allocate a single array of the 
right size) and then the MLton.PThread structure would actually create and 
destroy individual OS-threads, subject to the indicated maximum.