Re: Realtime SIGIO signals questions (linux)

From: Mike Richer (nospam_at_notachance.com)
Date: 07/24/04 

Date: Fri, 23 Jul 2004 19:49:55 -0400

Thanks a lot, you've been a great help.

In regards to the last piece, indeed when I close the sock the process it is
removed from the list, however I was concerned about already pending signals
when I perform the close. As in the example I provided, if i were in the
handler and decided to close the socket, and there was a pending signal for
that descriptor already, and I reopened a new sock from the same handler
before the pending signal is process, and that new socket re-uses the same
descriptor, when the handler gets invoced for the pending signal, I don't
know if I have stale data or new data. Is there no way to flush the pending
signals?

Mike

"sean larsson" <infamous42md@ERASEMEhotpop.com> wrote in message
news:20040723174223.1ec7ac41.infamous42md@ERASEMEhotpop.com...
> i checked the socket code, and it does remove the process from the list
when close is called, so that's not something u should be worried about.
but also,
>
> > > I receive a packet causing a SIGIO. While in the handler, more data
arrives,
> > > causing a SIGIO to be queued. While in the first instance of the
signal, I
> > > decide to close the socket and open a new one. The new decriptor uses
the
> > > same descriptor as the one I just closed. When the queued signal
fires, how
> > > does one determine whether or not I'm reading stale data, or data from
the
> > > new socket.
>
> you won't ever get "stale" data. when the socket is closed, pending data
is discarded.
>
> On Fri, 23 Jul 2004 21:32:55 GMT
> sean larsson <infamous42md@ERASEMEhotpop.com> wrote:
>
> > On Fri, 23 Jul 2004 16:38:38 -0400
> > "Mike Richer" <nospam@notachance.com> wrote:
> >
> > > I'm building a network/socket based application and thought I'd give
> > > realtime signals a go. I've gotten the application working so far on a
linux
> > > 2.4 based system, but there are a few mysteries left uncovered, and
I'm
> > > severly lacking in documentation. If anyone can answer a few of the
> > > following, that would definetly be appreciated.
> > >
> > > 1) Anyone know of any good coding examples / good documentation
surrounding
> > > POSIX.4 real time signals / real world implementations, specifically
around
> > > SIGIO would be great. I've scoured google with not too much luck.
> > >
> > http://www.kohala.com/start/unpv22e/unpv22e.html there is a directory
in the source code examples with real time signals.
> >
> > > Ok, now for the nitty gritty... Typically when coding non-realtime
signals,
> > > specifically the SIGIO signal, in the handler you poll to see which
file
> > > descriptors are ready and perform some form of action. You typically
have
> > > to "read" on these descriptors until there's nothing left to read
since
> > > signals won't queue and then you return. In real-time signals however,
the
> > > behaviour is a bit different. For one, in my current implementation
I'm
> > > setting SA_SIGINFO so that I'm notified which file descriptor the
signal is
> > > referring to. So here's the questions:
> > >
> > > 2) If multiple blocks of data are received on the socket, causing
multiple
> > > SIGIOs to be queued, when in the handler, how much will I "read"? In
other
> > > words, if 2 "blocks" of data are available on the socket before the
first
> > > SIGIO is caught and processed, and I were to read SSIZE_MAX worth of
data
> > > (assuming the data is smaller than that) in the first instance of the
> > > handler, will I get both blocks of data in the first instance, and
then
> > > read -1/EGAIN when the queued SIGIO fired?
> > >
> > depends on the protocol, with UDP you would read a record each read, and
with tcp you would read as much as u could. but yes, once u read all
available data you would get an EAGAIN or similar.
> >
> > > Since I somewhat ported my non-realtime version to the realtime
version of
> > > SIGIO, my current implementation reads everything there is before
return by
> > > issuing multiple "read"s until nothing is left, and then simply not
caring
> > > when "read" returns -1/EGAIN on successive queued SIGIOs on the same
> > > descriptor, so again, it works fine, I'm just wondering if I have to,
and if
> > > I don't, will read only return the amount of data which originally
triggered
> > > the signal, however multiple reads will pull it all out?
> > >
> > no, there is no relation between the amount of data available when you
call read and the amount of data available when the signal is delivered. in
linux, the sending of async i/o signals works like this:
> > + a process registers for async i/o, in the driver/kernel code a flag is
set to mark that file descriptor for async i/o
> > + in the kernel, when data arrives for that device, it goes thru the
list of processes waiting on async i/o and sends a signal to each one
> >
> > so as long as your process is registered, it gets sent a signal each
time data arrives to the underlying device. well, not device in this case,
but rather the socket layer.
> >
> > > 3) 3rd and my most important question is, how to properly handle
closed
> > > sockets. I've noticed that after closing a socket, specifially from
within
> > > the signal handler, it is possible that there are still pending
signals for
> > > that descriptor, so after closing the socket, I still sometimes
receive one
> > > or two signals with si_fd pointing to the closed descriptor, and my
read
> > > will return EBADF. My worry is the following scenario...
> > >
> > > I receive a packet causing a SIGIO. While in the handler, more data
arrives,
> > > causing a SIGIO to be queued. While in the first instance of the
signal, I
> > > decide to close the socket and open a new one. The new decriptor uses
the
> > > same descriptor as the one I just closed. When the queued signal
fires, how
> > > does one determine whether or not I'm reading stale data, or data from
the
> > > new socket.
> > >
> > > 4) So... when closing a socket, is there a way to flush any pending
queued
> > > signals for that descriptor?
> > >
> > continuing, in most driver code i have looked at, once the descriptor is
closed, the process is removed from the async i/o list and should NOT be
sent any more signals. perhaps someone else knows if something is different
with sockets??
> >
> > > Thanks in advance!
> > > Mike
> > >
> > >
> > >
> >
> >
> > --
> > -sean
>
>
> --
> -sean

Relevant Pages

  • Re: determining the freeze point of an already running process
    ... Maybe "pending 101" means something to someone. ... mask of the pending signals. ... stuck in state D. Processes get stuck in state D (and become ... NFS filesystem mounted, and the NFS server providing that filesystem ...
    (comp.os.linux.misc)
  • [PATCH 1/2] fix stop signal race
    ... CPU processes a SIGCONT or SIGKILL. ... checks for this case explicitly by looking for a pending SIGCONT or SIGKILL ... last time all pending stop signals were cleared due to SIGCONT/SIGKILL. ... The processing of stop signals checks the flag after the window where it ...
    (Linux-Kernel)
  • Re: [PATCH] [RFC] fix missed SIGCONT cases
    ... * the SIGCHLD was pending on entry to this kill. ... Remove all stop signals from all queues, ... If there is a handler for SIGCONT, ... Wake up the stopped thread _after_ setting ...
    (Linux-Kernel)
  • Re: Signals to cinit
    ... it can mask the next SIGKILL ... Currently, when the global init has the pending SIGKILL, we can't ... We can drop other SIG_DFL signals from the same namespace early as well. ... must know it can't reliably kill cinit with SIGTERM. ...
    (Linux-Kernel)
  • Re: simultaneous signal handling and setjmp/longjmp
    ... dealing with what happens if you call longjmp with pending signals. ... Suppose we have an app with multiple signals pending. ... If we run the SIGSEGV handler does the SIGALARM stay pending until the ...
    (comp.unix.programmer)