Re: Signals and the such-like

["Conrad Scott" <Conrad dot Scott at dsl dot pipex dot com>]

"Christopher Faylor" <cgf@redhat.com> wrote:
> >Currently the main thread doesn't wake up: the signal thread at
> >this point is running at a higher priority and since it doesn't
> >suspend (hopefully) the main thread will never get a chance.
>
> That is the point, however, if the main thread is waiting for
> signal_arrived, it does stand the chance of waking up.

Yep, that's true.  Okay, ditch one "fine" idea :-)

> >The idea was that setting the 'signal_arrived' event would help
> >prevent the signal thread from suspending and thus make it more
> >likely that the main thread would never run.  That's not quite
> >right of course, since the main thread may well be suspended on
> >the event and thus not runnable except for that.
>
> Why not just check if you are running with CurrentThreadId () ==
sigtid?

For a moment I thought that was it: but this doesn't catch the
situation where the application is exiting without closing the
socket.  Then the blocking close occurs in the exit code where
signals are being blocked.

> However, it still sounds like you have a blocking condition if
> the read is happening in another thread.

In the problematic scenario, the main thread is either closing the
socket (and is blocked in close already) *or* the program is
exiting, so this shouldn't be a problem.  If the main thread is
reading from the socket, it would block anyway since the problem
occurs only if the server is tardy about accepting the connection
and so cannot have written any data to the socket.

In all these situations, if the program is exiting, the close
should either not block or should be interruptible.  Currently it
has no idea (in general) that the program is exiting (and so
doesn't know not to block) and signals are being ignored (so it
can't be interrupted).

The best solution so far (from where I'm standing) seems to be a
global "exiting" flag.  Is that too unreasonable?

If it is, I could bung in a timeout but this could cause problems
if a server is *really* slow (i.e. the client will timeout, the
handshake won't occur, and the client message will be rejected).
I could return an error from close, but how many programs ever
test for that?

// Conrad