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

[Jörg F . Wittenberger]

On Sep 29 2011, Alan Post wrote:

> On Thu, Sep 29, 2011 at 01:11:49PM +0200, Jörg F. Wittenberger wrote:
> > On Sep 29 2011, 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
> >
> > There are two ways to fix that: either make the posix unit thread safe
> > (recall my recent message how to avoid process-wait having a bad effect).
> >
> > The other one is working around the problem.  That's what I'm doing based
> > on some code Felix supplied ages ago.  It wraps the file descriptors
> > into custom ports those are properly restarted on EINTR.
> >
> > However I'd be rather interested to learn what exactly the problem is
> > you observe.  Recently (maybe 4.7.3 or .4) I'm seeing missbehavior
> > from formerly well working code.  I can't say that's chickens fault
> > but neither I can say it's not.
>
> If I understand the part of the code below that wraps read/write, it
> can't be used as-is for my problem.  Because chicken defers signals,
> a signal is delivered, deferred, then read/write return with EINTR.

Ah, I see!  Good catch.

> If I immediately restart these syscalls (all in the same C call), the
> deferred signal has not be delivered, and the code deadlocks, as
> read/write pauses--blocking the signal handler from ever being run.

I'm not yet sure, but this could shed some light at the problems I
have.

However I normally see signal handling working all day long in my code.
Therefore I don't fully understand your issue yet.

Signal handlers as they are in chicken might be problematic.
I can't find the message, but I recall a reply these days, which
informed me that it's true that chicken interrupt handlers are
in fact in a restricted dialect of Scheme: they can not allocate memory.

I started to read into it.  I too, still don't understand all of the
C_reclaim procedure.  But it's obvious that the interrupt handler
is invoked at the begin of the garbage collection.  Wild guess:
there is no memory available for allocation at that time.

Attempt work around: defer the signal even more: until next schedule
time.  I'm not yet satisfied with that solution.  (But at least it
allows me to run arbitrary code in the signal handler.)
(I intended so far to try whether it would be better to run it close
to the finalizers; that is at the end of garbage collection.
But that again is just an experiment TBD.)

Given your situation I hope we can devise a better way.

I'd need to understand your situation better.

> I need a way to deliver deferred signals after a syscall returns
> EINTR, before restarting that syscall.

I see.  I understand you need "minimum latency" - right?

May I ask for more details.  I need to understand where this
latency requirement is important.

>  You may well not notice this
> in non-blocking code, as no data would be ready on the file
> descriptor and the code would continue running--eventually to
> deliver the deferred signal and unwedge everything

Sorry.  I do not have so many chicken programs.  As soon as something
blocks too often, I'll noticed a heavy slow down so far.
Under normal circumstances my prog uses 100-200 file descriptors
connected to pipes to subprocesses (which do network i/o+ssl) and
always on self-pipe.  Plus a few open sockets.

/Jörg