|
Home > Archive > Unix Programming > May 2005 > Sending signal on fd close
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Sending signal on fd close
|
|
| Rafal Krypa 2005-05-22, 5:49 pm |
| Hello.
I have a question:
One process of my program can block while probing semaphore (semop()).
I'd like the semop() function to return after file descriptor associated with
TCP/IP connection gets closed.
How do I stop the semop() function? Shall I use IPC_NOWAIT flag for semop() and
constantly check the connection status? Or maybe use F_SETSIG operation of
fcntl() function and properly handle SIGIO signal?
How do I know if the connection is closed without trying to read() from the fd?
Thanks in advance for your responses.
--
/"\ Rafal Krypa
\ / ===========
X ASCII Ribbon Campaign
/ \ against HTML mail
| |
| phil_gg04@treefic.com 2005-05-22, 5:49 pm |
| > One process of my program can block while probing semaphore
(semop()).
> I'd like the semop() function to return after file descriptor
associated with
> TCP/IP connection gets closed.
I think that you need to do fcntlt(F_SETSIG) to get SIGIO when the fd
closes. Of course you'll get it whenever anything happens on the fd.
Install a signal handler for SIGIO that does nothing (or nearly
nothing). Then, hopefully, semop() will return with errno=EINTR when
the signal arrives.
Good luck!
--Phil.
| |
|
| On 2005-05-22, phil_gg04@treefic.com <phil_gg04@treefic.com> wrote:
> I think that you need to do fcntlt(F_SETSIG) to get SIGIO when the fd
> closes. Of course you'll get it whenever anything happens on the fd.
> Install a signal handler for SIGIO that does nothing (or nearly
> nothing). Then, hopefully, semop() will return with errno=EINTR when
> the signal arrives.
Yes, but as far as I understand, the SIGIO signal will arrive whenever fd is
ready for input/output and on errors - how do I recognize that connection was
closed?
--
/"\ Rafał Krypa
\ / ===========
X ASCII Ribbon Campaign
/ \ against HTML mail
| |
| phil_gg04@treefic.com 2005-05-22, 5:49 pm |
| > Yes, but as far as I understand, the SIGIO signal will arrive
whenever fd is
> ready for input/output and on errors - how do I recognize that
connection was
> closed?
It's the same as reaching end-of-file on a regular file; read() returns
0.
--Phil.
| |
| Jens.Toerring@physik.fu-berlin.de 2005-05-22, 5:49 pm |
| Rafal Krypa <mail@iceberg.pl> wrote:
> One process of my program can block while probing semaphore (semop()).
> I'd like the semop() function to return after file descriptor associated
> with TCP/IP connection gets closed.
I don't understand this - how is a file descriptor getting closed while
you are blocked in waiting for semop() to return? Wouldn't it be you
that would close the file descriptor? Or did you mean that you want to
find out if the other side closed its side of the connection?
If the later is the case it looks as if what you would need would be
a function similar to select() that would allow you to check both
file descriptors as well as the state of semaphores. And such a
function, as far as I know, doesn't exist. So I would guess the only
solution is to poll for both events, i.e. calling semop() with
IPC_NOWAIT and then call select() for the file descriptor with the
value for the timeout being set to 0 (or something small if that's
acceptable). If select() tells you that a timeout occured (i.e. you
can't read from the file descriptor go back to checking for the
semaphore, if it tells you that you can read from the file without
blocking then do so and, in case the other side closed the connec-
tion, read() is going to return immediately with a return value of 0.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
| |
| Barry Margolin 2005-05-23, 2:48 am |
| In article <3fcb37F6ng2cU1@uni-berlin.de>,
Jens.Toerring@physik.fu-berlin.de wrote:
> Rafal Krypa <mail@iceberg.pl> wrote:
>
> I don't understand this - how is a file descriptor getting closed while
> you are blocked in waiting for semop() to return? Wouldn't it be you
> that would close the file descriptor? Or did you mean that you want to
> find out if the other side closed its side of the connection?
>
> If the later is the case it looks as if what you would need would be
> a function similar to select() that would allow you to check both
> file descriptors as well as the state of semaphores. And such a
> function, as far as I know, doesn't exist. So I would guess the only
> solution is to poll for both events, i.e. calling semop() with
> IPC_NOWAIT and then call select() for the file descriptor with the
> value for the timeout being set to 0 (or something small if that's
> acceptable).
A better solution might be to use threads. Have a thread that blocks on
the semaphore, and another thread that deals with the network socket.
When the socket thread notices that the connection has closed, it can
kill the semaphore thread.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
|
|
|
|
|