Re: [Chicken-users] replace signal with sigaction

[Jörg F . Wittenberger]

On Sep 30 2011, Alan Post wrote:

> Thank you for this.
>
> I notice, right away, that your io_needs_restart handles EAGAIN in
> the same way it handles EINTR.  I have always introduced a timeout
> when I get an EAGAIN, and I give up after say 3 tries.

While I can follow the reasoning, it might not (or may?) apply in
the case at hand.

The select(2) call will not be restarted right away.
First the signal handlers will be run.  Those might change the
set of fd's in the set of ongoing i/o.
Alternatively those might have unblocked handler threads.
The Scheduler will run them before it retries.
Next it will try the timeout queue.  Though since we've been unblocked
for a different reason, this is probably not due (except if it took
long enough to run the signal handlers.

At worst nothing has changed.  Then, after giving one time slice to
all threads which are ready, the select is restarted.  Using a new timeout.

IMHO this level of dealing with i/o should not at all impose any wild
guess of timeouts.

Iff the i/o was interrupted, then try to schedule the close(fd) before
the next retry (the scheduler can't help in case the client thread refuses
to close the fd, but it will defend: next time this is going to be a BADFD
and it is free to signal an exception in the thread).


NB: At higher level I usually have a timeout/retry loop with exponential
back off.