Which events generate SIGIO ?

[Dag H. Wanvik]

[Please reply to borsting at kvatro.no (I posted this for him)]

We are developing a run-time system for CHILL, a concurrent language
with similar properties to Ada (only "more" asynchronous).
Our problem is how to make I/O as "asynchronous" as possible in Unix
processes when executing a CHILL program containing several concurrent
threads inside one Unix process (BSD, SCO Unix flavors).

Our basic problem is to precisely determine *when* and *why* (as a
result of which actions)  SIGIO is generated. In the following, some
assumptions are made based on reading relevant (I think) manual pages
(2 and 4, e.g. filio(4)). 

SIGIO is in the manual page for SIGVEC(2) described as:
    "I/O is possible on a descriptor (see fcntl(2V))"

Is there literature available that will guide me through the
following questions? Partial answers are also welcome! (Questions are
numbered for ease of reference.)

I. Disk I/O (write)

A disk file is opened for (sequential) writeonly. *fcntl* is called to
set the descriptor flags of that file to non-blocking (FIONBIO) and/or
(?)  asynchronous I/O (FIOASYNC). 

#1? What is the difference between FIONBIO and FIOASYNC?

#2? Is a SIGIO generated as a result of the *fcntl*-call (telling that the
first *write* call to that file can be performed)
*or*
is a SIGIO generated as a result of  the first *write*-call 
indicating that the next *write* can be done?

#3? If the file is to be written after positioning with *lseek*, will the
call to *lseek* cause the generation of a SIGIO when the positioning is
completed an data may be written?

II. Disk I/O (read)

A disk file is opened for (sequention) readonly. *fcntl* is called to
set the descriptor flags of that file to non-blocking (FIONBIO) and
asynchronous I/O (FIOASYNC). 

#4? Is the first SIGIO generated as a result of the *fcntl*-call (telling that
the first read call to that file can be performed)?

#5? Will a new SIGIO be generated after each read-call as long as there are
data left to read in that file?

#6? If the file is to be read after positioning with *lseek*, will the call
to *lseek* cause the generation of a SIGIO when the positioning is
completed an data may be read?

III. Disk I/O (read/write)

#7? Is the async behaviour of files opened for both reading and writing in
conformance with the readonly/writeonly behaviour?

IV. stream socket I/O (accept)

An AF_INET stream socket is created and bound (call to *bind*) to a proper
port. *fcntl* is called to set the descriptor flags of that socket to
non-blocking (FIONBIO) and asynchronous I/O (FIOASYNC). 

#8? Is a SIGIO generated without doing any further calls (telling that
an *accept*-call can be made i.e. when the first incoming connect request
has arrived) ?

V. stream socket I/O (connect)

An AF_INET stream socket is created. *fcntl* is called to set the
descriptor flags of that socket to non-blocking (FIONBIO) and
asynchronous I/O (FIOASYNC). 

#9? Will the call to *connect* return immediately and a SIGIO be generated
when the connect call is completed? 

#10? Will a close on a socket awaiting a connect completion (once the close has
completed) guarantee that a SIGIO will not be generated for that
connect call, or doesn't it matter (i.e. the succeding call to select will
find nothing)?

VI. Disk file manipulation

#11? Is it possible to make calls to *stat*, *creat* and *open* (e.g.
on files in a mounted directory of a remote disk) non-blocking and
asynchronous? 

VII. IPC message queues

#12? Is there any way of making IPC message queue call *msgrcv* (possibly
also *msgsnd*) non-blocking *and* asynchronous? It seems that the IPC_NOWAIT
flag merely gives you a (non-blocking) polling feature, and not the
generation of a signal once an operation is, or can be, completed.


Answers or proper literature references will be MUCH appreciated. :-)

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dag H. Wanvik  ,   Senior Systems Engineer
Mailing address:   KVATRO AS, Pirsenteret, N-7005 Trondheim, NORWAY
Telephone      :   +47 7 520090
Fax	       :   +47 7 520140
Internet e-mail:   wanvik at kvatro.no [my VAX/VMS address]
          or   :   dag at kvatro.no    [my Unix address]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~