[MLton] interrupted system call

[Matthew Fluet]

>> Have you made any progress on putting together an example of an interrupted 
>> system call raising an exception?  I'll reiterate that it doesn't really 
>> matter how small the example is, so long as it exhibits the bad behavior.
>
> Indeed I have, the problem seemed to occur because I had a atomicBegin/End 
> wrapped around a Socket.recvVec call (not directly wrapped, but logically 
> around the blocking system call). Removing this atomicBegin/End, resulted in 
> the exception no longer being thrown.

Hmm.  I still think that violates the behavior we want:

   http://mlton.org/MLtonSignal

   A system call that must be restarted while in a critical section will be
   restarted with the handled signals blocked (and the previously blocked
   signals remembered). This encourages the system call to complete,
   allowing the program to make progress towards leaving the critical
   section where the signal can be handled. If the system call completes,
   the set of blocked signals are restored to those previously blocked.

You should be calling Socket.recvVec in a critical section, as the socket 
has some shared state which is manipulated during the call.  So, I would 
expect the system call to be attempted, interrupted by the signal, the 
signals blocked, the system call restarted, and finally the signals 
unblocked.  I suppose that the restarted system call could fail, but I 
find it odd that it fails with an interrupted exception, as all signals 
should be blocked for the duration of the restarted system call.

> I can happily pack up the non-working 
> version of eXene and send it your way if you want a large example.

Yes please. That would be helpful.

> I have also figured out why I got the internal type error when compiling with 
> keep exception history true.  I forgot I added a packword16 functor to my 
> basis, when compiling with the normal MLton basis, I do not see the internal 
> type error (so this atleasts narrows down the problem to a few lines of code 
> for you). I will mail this code along with the broken eXene version, since 
> packword16 is needed by eXene.

Great.

> Lastly, I have a basic port of eXene working now, which I will send to the
> list shortly (I still would like to do some more tests with larger programs, 
> and finish up porting all the small test cases, the widgets also need to be 
> ported, but the core of eXene seems to be working). All this work was done 
> with Philip Schatz, and undergraduate here at Purdue who is interested in ML 
> and MLton.

Cool.  Are you basing your work off of the "old" eXene from Bell Labs or 
the "new" eXene from Kansas State?