[MLton] More on Parallel Runtime

[Eric McCorkle]

On Oct 20, 2007, at 9:13 PM, skaller wrote:

>> I have tested this code with a few programs that spawn a simple
>> "executor" on multiple pthreads. Currently I'm trying to get CML  
>> working
>> using this model and have run into a little snag getting signal  
>> handling
>> to work (CML uses preemptive threads). Well-defined safe-points  
>> would be
>> an elegant way to overcome this.
>
> But very inefficient, even if you can optimise placement of safe- 
> points,
> you will need one in every tight loop. This is probably not  
> acceptable.

That's an implementation detail.  A way around this specific case  
might be to unroll the loop, or only check the mailbox every 16th,  
32nd, or whatever-th loop execution.  The point is, I'm assuming safe- 
points occur "at reasonable intervals".  It should be possible to  
build a smart safe-point generator that weaves them into pipeline  
stalls, ensure no more than some k cycles pass between each safe- 
point, et cetera.

> Have you seen how Boehm's collector does thread management?
> It varies from platform to platform, and each implementation
> has problems, but it is trying to work with arbitrary existing
> C and C++ code, so a dedicated ML system should be easier.

C/C++ don't have sound type systems, and their code output has no  
type signatures.  Boehm relies on very specific knowledge (ie GCC  
version 4.1 puts k padding bytes...).  MLton and other compilers for  
strongly-typed languages create signatures that tell you what  
everything's type is.  Personally, I believe this is the way of the  
future, based on the recent TAL (typed assembly language) work.

Of course, in C, there's still the problem that I can cast anything  
to anything, which makes a perfect solution impossible.  I could  
probably break Boehm by doing something heinous like casting a  
pointer to an int, xoring it with 0xaaaaaaa, and later xor'ing and  
dereferencing it again.

-- 
Eric McCorkle
Brown University
CS Graduate Student