[MLton] interrupted system call
Lukasz S Ziarek
lziarek@cs.purdue.edu
Tue, 23 Aug 2005 11:28:44 -0500 (EST)
Your response seems to imply that my user level threads will never see
OS.syserr where the error is interupted system call? 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 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?
thank you
Luke
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
>