aio_connect ?

[Igor Sysoev]

On Wed, 20 Oct 2004, Ronald F. Guilmette wrote:

> > and they require too many syscalls.
> >E.g, the reading requires
> >*) 3 syscalls for ready data: aio_read(), aio_error(), aio_return()
> >*) 5 syscalls for non-ready data: aio_read(), aio_error(),
> >   waiting for notification, then aio_error(), aio_return(),
> >   or if timeout occuired - aio_cancel(), aio_error().
>
> This assumes that one is _not_ using the signaling capabilities of the
> aio_*() functions in order to allow the kernel to dynamically signal the
> userland program upon completion of a previously scheduled async I/O
> operation.  If however a programmer were to use _that_ approache to de-
> tecting I/O completions, then the number of syscals would be reduced
> accordingly.

Yes, nginx does not use the AIO signaling capabilities. With signals
you do not call the syscall that waits the completion. But the call of
the signal handler requires 3 context switches instead of 2 switches
in the case of syscall.

> However this all misses the point.  As I noted earlier in this thread,
> efficience _for the machines_ is not always one's highest engineering
> design goal.  If I have a choice between building a more maintainable,
> more adaptable, more modularized program, or instead building a more
> machine-efficient program, I personally will almost always choose to
> build the clearly, more modularized program as opposed to trying to
> squeeze every last machine cycle out of the thing.  In fact, that is
> why I program almost exclusively in higher level languages, even though
> I could almost certainly write assembly code that would almost always be
> faster.  Machine time is worth something, but my time is worth more.

I believe if you want to build a more maintainable, more adaptable,
more modularized program then you should avoid two things - the threads and
the signals. If you like to use a callback behaviour of the signals you could
easy implement it without any signal.


Igor Sysoev
http://sysoev.ru/en/