Help needed with sockets & signals

Help needed with sockets & signals

Post by le.. » Sun, 02 Oct 1994 06:54:24



Greetings,
    I have an application which needs to send message blocks between two or
more processes on different machines.  The messaging needs to be TOTALLY
asynchronous and portable between different flavors of BSDish UNIX.  The
current design sends, receives, packs, and unpacks messages within a SIGIO
handler setup via sigvec.  FDs ready for processing are selected with select()
within the signal handlers.  All message processing takes into account partial
I/O.  I know signal handlers are expensive, but threads and heavyweight
processes are not an option for various reasons.  Critical sections are all
bracketed with sigblock (...) --- setsigmask (...) pairs.  Critical sections
are defined in this application as areas of conflict between the user code
and the I/O signal handler.

The problem:  In a test application there are two processes P1 and P2.  P1
creates a series of messages (4 - 65K random bytes in length) and P2 loops
the messages back to P1.  After processing N messages both P1 and P2 hang
in the write system service.  Both P1 and P2 utilize non-blocking signaling
I/O on all sockets.  Netstat reports the sockets' Send/Receive queues have
data to process, in one case the data in at least one queue on the same
host is equal to the value returned by getsocketopt (SO_SNDBUF).  P1's ps
WCHAN status reports `socket'.

P2 also has a signal handler for SIGHUP used to report various conditions of
the internal processing.  When a SIGHUP is sent to P2, the I/O system seems
to free up for another write cycle and then the hang-up occurs again.

Questions:

    1)  Is there a known conflict/problem with performing I/O within a
        signal handler?  If so, are there any know solid workarounds.

    2)  Where in the I/O processing are the conditions for EWOULDBLOCK
        evaluated?

    3)  Any other ideas or comments welcome as to the design problem.

Please e-mail/post.  E-mail is preferred, will summarize e-mail responses
if there is interest.

                                        Thanks,
                                            Greg Leach

-----------------------------------------------------------------------------


P.O. Box 3999  M/S 9F-61  |
Seattle, WA  98124-2499   | Phone:     (206) 657-6379
-----------------------------------------------------------------------------

 
 
 

1. Help needed with sockets & signals (REPOST)

This is a reposting of a question posted on comp.unix.programmer with some
minor revisions.  Because of the short message window my news host has,
PLEASE e-mail responses.  I will summarize.

---- original message with revisions ----

Greetings,
    I have an application which needs to send message blocks between two or
more processes on different machines.  The messaging needs to be TOTALLY
asynchronous and portable between different flavors of BSDish UNIX.  The
current design sends, receives, packs, and unpacks messages within a SIGIO
handler setup via sigvec.  FDs ready for processing are selected with select()
within the signal handlers.  All message processing takes into account partial
I/O.  I know signal handlers are expensive, but threads and heavyweight
processes are not an option for various reasons.  Critical sections are all
bracketed with sigblock (...) --- setsigmask (...) pairs.  Critical sections
are defined in this application as areas of conflict between the user code
and the I/O signal handler.

The problem:  In a test application there are two processes P1 and P2.  P1
creates a series of messages (4 - 65K random bytes in length) and P2 loops
the messages back to P1.  After processing N messages both P1 and P2 hang
in the write system service.  Both P1 and P2 utilize non-blocking signaling
I/O on all sockets.  Netstat reports the sockets' Send/Receive queues have
data to process, in one case the data in at least one queue on the same
host is equal to the value returned by getsocketopt (SO_SNDBUF).  P1's ps
WCHAN status reports `socket'.

P2 also has a signal handler for SIGHUP used to report various conditions of
the internal processing.  When a SIGHUP is sent to P2, the I/O system seems
to free up for another write cycle and then the hang-up occurs again.

Questions:

    1)  Is there a known conflict/problem with performing I/O within a
        signal handler?  If so, are there any know solid workarounds.

    2)  Where in the kernel I/O processing are the conditions for EWOULDBLOCK
        and the descriptor ready states for select evaluated?

    3)  Does the socket inform the kernel of blocking conditions?

    4)  Any other ideas or comments welcome as to the design problem.

                                        Thanks,
                                            Greg Leach

-----------------------------------------------------------------------------


P.O. Box 3999  M/S 9F-61  |
Seattle, WA  98124-2499   | Phone:     (206) 657-6379
-----------------------------------------------------------------------------

2. Bash redirection question

3. Signal handlers & semaphores & sockets

4. survey says

5. HELP: Signals & Sockets

6. Fonts degrade in accelX

7. KDE 2.2 OpenGL issue

8. help needed for pthread questions (C++, signal & timer)

9. Setting a Signal handler to signal the input on a socket

10. signal handling & sockets

11. socket functions & Signal Handler

12. sockets & signal