NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/wizards/3825

Internet Message Format | 1992-09-08 | 3.5 KB

Path: sparky!uunet!olivea!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Newsgroups: comp.unix.wizards
Subject: Re: Async IO problem
Message-ID: <[e-mail]>
Date: 7 Sep 92 08:58:01 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
Lines: 66

In article <[e-mail]> [e-mail] (chung wai man) writes:
>Hi!
>
>I have some problem about Async IO. In the Unix Network Programming
>by Stevens, on P.327, it has an example program telling how to make
>async IO. It has the codes:
>
>    sigblock(sigmask((SIGIO));
>    while(sigflag == 0)
>      sigpause(0);eee(0)
>
>I wonder if these codes are necessary for Async IO. These codes seems that
>the program will halt and wait for a signal. If it is so, it is just a
>blocking socket waiting for something to receive.
>
>My concept for Async IO is that it is like a software interrupt. The
>program can go along. When something has received, it will be interrupted
>, doing a routine already registered for signal SIGIO, then
>resuming.

Sorry, but it isn't an interrupt.  It's a persistant condition.  You are
not guaranteed a 1:1 correspodance between SIGIO signals handled by your
handler and the conditions which cause the SIGIO signals to be sent to
your process.  This is beacuse signal delivery is blocked in the handler
and only 1 signal thereafter is marked until handler exit.

The code in the Steven's book shows the use of async I/O to multiplex
input sources that generate SIGIO without buzz-looping.  This is because
you check all possible sources after the wakeup.  That way if multiple
channels have data simultaneously, you either handle it as a result of
falling through sigpause(), or when you loop back up you fall through
and handle it anyway (if a secong SIGIO occurs after that particular
I/O source has been checked for the condition causing the SIGIO but before
restarting the sigpause().)

Signals are not events, and signal handlers therefore can not be event
handlers.  Period.  If you try to use them that way, the code will be
unreliable in the multiple-signals-during-handler case.  Period.

A better mechanism for async I/O, if you are using SunOS or AIX, is to
use the async I/O routines.  In the Sun implementation, this requires
that you enable the ASYNCIO kernel option, and that the driver for the
input source in question support the async flag.

I you absolutely *must* use multiple input sources, and either are not on
AIX/SunOS, or your device driver is bad, try poll() and select().  Failing
this, you can set up one child listener process per input source and write
a common pipe back to the parent.

If you wait to write your program until your vendor adopts POSIX 1003.4,
implements it, and ships you a copy, then you can have reliable signal
delivery and queued multiple instances of a particular signal, thus
guaranteeing a 1:1 relationship.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                                       [e-mail]
 "I have an 8 user poetic license" - me
-------------------------------------------------------------------------------