[MLton] interrupted system call

[Lukasz S Ziarek]

On Tue, 30 Aug 2005, Matthew Fluet wrote:

>
> Luke,
>
> 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.

Mathew,

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

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.

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.


thank you,
Luke



>
>
> On Tue, 23 Aug 2005, Matthew Fluet wrote:
>> 
>>> Your response seems to imply that my user level threads will never see 
>>> OS.syserr  where the error is interupted system call?
>> 
>> Correct; I believe that this is the behavior we want.
>> 
>>> In eXene there are a few threads which have catch all handlers which 
>>> simply exit the thread if any exception is thrown. I have cased on these 
>>> and found the exception they are receiving is interupted system call, 
>>> which you implied I should never see. Should I allow this excpetion to 
>>> propogate to the runtime, or is this a bug and I should not even see this 
>>> exception in my user defined handlers?
>> 
>> I'm tempted to call it a bug, though it will depend on the precise system 
>> call that is raising the exception.  The interrupted sys call exception 
>> should never be explicitly raised when the system call is to be restarted 
>> (see basis-library/posix/error.sml).
>> 
>> I can see a couple of different reasons that you might see the exception:
>> 1) the system call is being interrupted for some reason other than
>>    signals
>> 2) some system call in the Basis Library is not wrapped correctly by the
>>    restarting wrapper.
>> 
>> 2) is the more likely explaination, so it would be desirable to figure out 
>> which system call is raising the error.  I believe
>> -const 'Exn.keepHistory true'  will work in a multi-threaded program, so if 
>> you just let the exception propagate to the top level, you should see a 
>> history that narrows down where the exception is coming from.
>> 
>>> I can write up a quick test for this, if this indeed is the problem, or is 
>>> it my error (exene) that the handler catches everything?
>> 
>> If you can come up with a test case, that would be great.
>> 
>>> On Mon, 22 Aug 2005, Matthew Fluet wrote:
>>> 
>>>> 
>>>>> I would like to just confirm that all blocking system calls, in a 
>>>>> multi-threaded MLton compiled program, will infact yield an interrupted 
>>>>> system call exception upon context switching to a new thread due to 
>>>>> timer interupts?
>>>> 
>>>> Actually, we should be doing the opposite.  See the discussion at the 
>>>> bottom of
>>>>  http://mlton.org/MLtonSignal
>>>> 
>>>> You should, be default, not see exceptions from interrupted system calls; 
>>>> instead, the system calls will be silently restarted when the thread is 
>>>> resumed.
>>>> 
>>>>> I am mainly interested in socket calls. This is the behavoir I observe 
>>>>> when one thread atempts to read from a socket, blocks, and then the 
>>>>> program attempts to context switch to another thread.
>>>> 
>>>> That isn't the behavior I would expect from our stated philosophy on the 
>>>> web-page above.  Could you post the code that is yielding this behavior?
>>>> 
>>>> _______________________________________________
>>>> MLton mailing list
>>>> MLton@mlton.org
>>>> http://mlton.org/mailman/listinfo/mlton
>>>> 
>>> 
>>> _______________________________________________
>>> MLton mailing list
>>> MLton@mlton.org
>>> http://mlton.org/mailman/listinfo/mlton
>>> 
>> 
>> _______________________________________________
>> MLton mailing list
>> MLton@mlton.org
>> http://mlton.org/mailman/listinfo/mlton
>> 
>