Re: Realtime SIGIO signals questions (linux)

From: sean larsson (infamous42md_at_ERASEMEhotpop.com)
Date: 07/23/04 

Date: Fri, 23 Jul 2004 21:39:21 GMT

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

  • [UNIX] OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals
    ... OpenBSD Bug Allows Unprivileged Users to Send SIGURG and SIGIO Signals ... Which process is notified depends on the ownership of the file descriptor. ... calls the socket function in the case of sockets). ...
    (Securiteam)
  • Realtime SIGIO signals questions (linux)
    ... POSIX.4 real time signals / real world implementations, ... SIGIO would be great. ... setting SA_SIGINFO so that I'm notified which file descriptor the signal is ... If multiple blocks of data are received on the socket, ...
    (comp.unix.programmer)
  • Realtime SIGIO signals under linux
    ... POSIX.4 real time signals / real world implementations, ... SIGIO would be great. ... setting SA_SIGINFO so that I'm notified which file descriptor the signal is ... If multiple blocks of data are received on the socket, ...
    (comp.unix.programmer)
  • OpenBSD bug
    ... default behaviour in OpenBSD is to ignore these signals, ... arrives to an specific file descriptor, ... calls the socket function in the case of sockets). ...
    (Bugtraq)
  • Re: buffering SIGIO instances
    ... i am using fcntl() to raise a SIGIO whenever there is data to ... >> be read from that socket. ... Note also that there are limits on the number of real-time signals ...
    (comp.os.linux.development.apps)