Re: [Chicken-users] EINTR with self-pipe signal trampoline

[Alan Post]

On Wed, Sep 28, 2011 at 05:29:46PM -0601, Alan Post wrote:
> Below is a test case for a problem I'm seeing in some multi-process
> code I'm writing.  I'm getting the error:
> 
>   Error: (file-read) cannot read from file - Interrupted system call
> 
> because a signal handler is going off while my main thread is in an
> iowait state.  In C, I have always handled this by manually
> restarting a system call when EINTR is called.  In my attached test
> case, I'm trying to use SA_RESTART in sigaction(2) for the same
> affect, and that isn't working for me.  Does that actually work?
> 
> I'm trying to determine which direction to head in to fix this
> problem, and I was surprised that SA_RESTART didn't work.  Will one
> of you with access to a linux machine try running this code?  Both
> in the version as seen here and also run uncommenting the two
> "foreign-code" lines.
> 
> This code might have bugs that prevent it from running as
> intended--I'm not able to test past my EINTR problem.  I'm now
> planning on patching file-read and file-write to restart on EINTR,
> unless someone has a better idea!  Can I catch this exception at
> runtime?
> 
> -Alan
> 

I investigated this further last night and can articulate better the
problem.

 1) The main thread sets a signal handler.
 2) In then calls read(2) and blocks.
 3) A signal arrives, which is handled by an internal signal handler.
 4) read(2) returns -1 with errno set to EINTR.

What I need to have happen here, is for the signal handling code to
then be run, which will write(2) to the pipe.

I then need the signal handler to be run (which happens on the main
thread)

At which point I *then* need to restart the read(2) call, which now
will have pending data.

I can't introduce a version of read(2) that restarts on EINTR: doing
that causes the signal handler to never be run, so we pause forever
in a deadlock.

I don't understand enough about the scheduler to know when
interrupts get handled.  Can it happen while executing the scheme
code in file-read?  If signals get delivered at a reliable point,
read can likely be restarted knowing the signal has been handled.
If not, I'm left with needing to catch the error, somehow guarantee
that the signal handler has been run, then call my code again (to
re-enter read)

When does the scheduler handle interrupts?

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du