In message <[EMAIL PROTECTED]>, you wrote:
>> Anyway, upon further reflection (and further RTFM'ing) I am now inclined
>> towards a distinct dislike for the entire aio_*() family of functions
>> because, as I just now realized, they provide the programmer with a
>> synchronous way (i.e. the aio_error function) of checking for inherently
>> _asynchronous_ events, i.e. I/O completions. All things considered, I
>> think that I personally would prefer to receive such notifications (of
>> asynchronous I/O completions) via interrupts... er... I mean via signals.
>>
>> (I suppose that there is some way of doing that, but I confess that I per-
>> sonally have never come across it, so if anybody wants to educate me, then
>> by all means please do so.)
>
>man kqueue.
I am familiar with kqueue, and I wrote an early example program to illustrate
its use:
http://www.monkeys.com/freeware/kqueue-echo.c
But that facility (kqueue/kevent) does not provide the kind of asynchronous
I/O completion interrupts that I was asking about. Rather, it is just a
different (and significantly more efficient) way of doing essentially the
same things as you can do with either select() or poll().
>And have a look at libevent by Niels Provos. Saves the day.
Hummm... I did a google search on that and started to read this page:
http://www.monkey.org/~provos/libevent/
(As a monkey myself, I supposed that I should have already known about this,
but I didn't. :-)
Anyway, reading that page was rather enlightening, and it gave me some other
clues that I tracked down. Those caused me to realize that the aio_*()
family of functions is _not_ hopeless after all, and that they _can_ trigger
exactly the kinds of asynchronous I/O completion signals that I was asking
for... although that fact is very poorly (un-)documented in the relevant
FreeBSD man pages (on 4.10-RELEASE) for the aio_*() functions. (Those man
pages need a LOT of work.)
Anyway, as I have just learned, the async I/O control blocks used by, for
example, aio_read() and aio_write() contain a field named `aio_sigevent'
that allows the user to request, in advance, that some specific signal be
delivered when the requested I/O operation completes. This is _exactly_
the kind of thing that I earlier said would be a Good Thing To Have.
So anyway, I am pleased to see that, after all, it _is_ possible to pro-
gramatically ask to be interrupted (via a signal) when a given async I/O
operation completes. That's the good news. The bad news is that... just
as I noted in the posting that began this thread... there is no such thing,
at present, as an aio_connect() function. :-( Bummer!
Anyway, I'd like to now repeat the ``request for enhancement'' that I put
forward in the posting I made that started this thread. The reasons why
the functionality of such a (hypothetical) new function would _not_ be
redundant with the functionality provided by other kernel calls (e.g.
connect() on a NOWAIT descriptor, followed by select()/poll()) are now
quite clear and evident. A call to connect() followed by a call to select()
or poll() to detect completion of the asynchronous connect() is a funda-
mentally _synchronous_ (manual polling) approach to the problem of detecting
the completion of an asynchronous connect() attempt. But if there existed
an aio_connect() function, then via the `aio_sigevent' field of the
async I/O control block (struct aiocb) passed to such a function the
caller could request _asynchronous_ notification (via a signal) of the
subsequent completion of the asynchronous aio_connect() call. (And let
me say that I dearly wish that I had _exactly_ this functionality RIGHT
NOW. It would help a lot for one project I am working on.)
In short, many of the reasons for having an aio_read() function are, in
my opinion, equally applicable to a (hypothetical) aio_connect() function.
In an ideal Universe... or even in just an ideal kernel... both should
exist, as they both would/could provide an asynchronous (signal-based)
notifications of completion events... a kind of functionality that clearly
cannot be duplicated with any other existing kernel calls, or even with
any combinations thereof.
Unless someone comes up with a compelling counter-argument, I will shortly
be submitting a ``request for enhancement'' PR that asks specifically for
the addition of a new aio_connect() kernel call.
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
