aio_connect ?

[Ronald F. Guilmette]

In message <200410201553.i9KFreme014552 at khavrinen.lcs.mit.edu>, you wrote:

><<On Tue, 19 Oct 2004 17:19:03 -0700, "Ronald F. Guilmette" <rfg at monkeys.com> said:
>
>> That's it for now... just aio_connect() and aio_accept().  If I think of
>> something else, I'll let you know.
>
>[lots of Big Picture(R) stuff elided]
>
>This is certainly an interesting model of program design.

It is very gentlemanly of you to say so.  Thank you.

>However,
>some caution is advised.  Here are the most significant issues:
>
>- FreeBSD doesn't really support POSIX real-time signals,

I think that is entirely orthogonal to the issue we were discussing, which
was just async I/O.  There is no clear or obvious dependence of aio_*() on
anything which could be called ``real time'', in the traditional sense.
I certainly _do not_ expect that if I made use of aio_*() functions (with
signaling) that I and/or my userland program would then receive notifications
of I/O completions within any given small interval after the I/O completions
actually occured.  There might be big time lags before _I_ actually receive
the completion notifications, e.g. if other higher priority processes get
scheduled before mine.  That's OK.  Even if the aio_*() functions don't
give me any sort of ``real time'' capabilities, I still do like the
``interrupt me when you are done'' model of I/O _and_ especially what it
might allow me to do in the way of better modularizaion of the programs
I have which need to do different things on different sockets concurrently.

>and I
>don't know whether the AIO code implements the signal mechanism at
>all.  (I believe it's conditional in the specification on AIO && RTS.)

Well, I don't actually _have_ copies of the more recent POSIX standards...
I actually have nothing fresher than about 1992... so I can't easily check
that.  (I wish that I did, but those documents tend to be EXPEN$IVE.)

In any case, it makes no difference.  The bottom line is that aio_*()
with signaling capabilities (for completions) would be a Nice Thing To
Have, regardless of which standard(s) such capabilities are or are not
required in.

>- There's very little you can safely do in a signal handler other than
>post a "complete" flag (of type volatile sig_atomic_t) somewhere, or
>call a small number of POSIX-specified functions.

Yes, yes.  I know.  (I was on the ANSI C language standard comittee for
awhile, long long ago, so I am well familiar with sig_atomic_t and also
all of the arcane _theoretical_ limitations regarding what can and can't
be done, standard-conformantly, in a signal handlers.  But of course we
both know that in addition to just writing sig_atomic_t thingies, in
practice it is possible to do lots lots more without actually breaking
anything.  And if one uses ``thread safe'' libraries, then you can get
away with doing even more in/from a signal handler.)

>- Even worse, the POSIX committee just discovered that the behavior of
>asynchronous signals is (thanks to changes in C99) now almost
>completely undefined.

Umm... Could you elaborate on that please?  Where could I find more infor-
mation about what you just said.  I _relly_ want to read about this.