[MLton] interrupted system call

[Lukasz S Ziarek]

Matthew Fluet wrote:

>
>>> 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 do not think the interaction is as simple as having atomics wrapped 
around the system call, since simple test cases seem to pass, but 
removing them did solve our problem with the exception.  We opted to use 
spin locks to ensure socket consitency, it is not especially ellegant, 
but it keeps us from having to wrap the system calls with atomics 
(avoiding the interrupted 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?
>
Currently this is the old eXene, the new eXene is not quite done yet 
from my understanding.

> _______________________________________________
> MLton mailing list
> MLton@mlton.org
> http://mlton.org/mailman/listinfo/mlton