inclusion of ivykis into GNU C library?

[Lennert Buytenhek]

Hi!

ivykis (http://sf.net/projects/libivykis) is a library for asynchronous
I/O readiness notification.  ivykis typically takes over the main loop
of applications that use it -- the application can register file
descriptors and timers with ivykis, and then call into ivykis' main
loop, and ivykis will call the right callbacks at the right times.
The API to me feels rather clean, and the implementation is small and
self-contained.

I asked Richard Stallman whether he would consider branding ivykis as a
GNU package (my original email attached below), and he suggested that it
would maybe make sense to make ivykis part of the C library.

I would like to ask you whether you could perhaps have a look at ivykis,
perhaps give me some feedback on the architecture, and maybe provide me
some clue as to what the chances are of the suggested inclusion actually
taking place.

Thanks!  Much indebted.


cheers,
Lennert



=============================================================================
Date: Thu, 14 Aug 2003 06:30:22 -0400
To: address@hidden
Subject: ivykis, an async I/O library, as GNU package?
From: address@hidden

Hi,

I would like to submit ivykis (http://sourceforge.net/projects/libivykis/)
for consideration as a GNU package.

ivykis is an asynchronous I/O-assisting library.  What this means is that it
acts as a simple, thin wrapper over OS facilities such as poll(2), select(2),
or whatever facility the underlying OS has.  ivykis completely replaces the
main loop of applications based on it.  The application registers file
descriptors and timers with ivykis, and ivykis invokes supplied callback
functions at the right times.


I think having something like ivykis is necessary.

What most programs that do network I/O end up doing is to just use select(2)
or poll(2) in their main loop, since that is the only interface that is
'guaranteed' to work on their target platform as well as other platforms.

But select(2)/poll(2) have their problems, the most apparent of which is
the fact that they don't scale well when handed large numbers of file
descriptors to poll (The amount of work needed is O(n) in the number of
polled file descriptors, not O(n) in the number of active file descriptors
as it should be.)  In real-life network applications, this is a very big
problem.  See http://www.kegel.com/c10k.html for more details.

When later on confronted with the inherent limitations of select(2)/poll(2),
developers usually recode their application to make use of a better-performing
event delivery mechanism, such as kqueue(2), /dev/poll or epoll.

But, these delivery mechanisms are not standardised, and generally not
portable.  And, developers have to make a choice between either maintaining
select(2)/poll(2) support in their application, which increases the
maintainance burden, or to drop select(2)/poll(2) support completely, which
makes their program non-portable.

These considerations probably explain why, for example, the GNU glib library,
on which gtk+ and the entire GNOME suite is based, still uses poll(2) for its
main event loop.

ivykis was made to address these problems.  Depending on the platform it
was compiled for and the at-runtime detected features of the running kernel,
it selects the optimal event delivery mechanism, and hides this behind the
library's thin abstraction layer.  On BSD systems, it will generally use
kqueue(2), on Solaris it will use /dev/poll, on GNU/Linux it will try to use
/dev/epoll or epoll_create(2) (depending on running kernel features).

Taking the same example, it would be an easy task to extend GNU glib to
make use of ivykis instead of using poll(2) directly, with all the advantages
mentioned above transparently available to all gtk+ and GNOME applications.


The source code to ivykis can be found at the above-mentioned URL
(http://sourceforge.net/projects/libivykis/).  ivykis is released under
the GNU Lesser General Public License, version 2 or later.

ivykis was originally developed for an in-house project for the company
that I currently work for, and when I decided to split it off, clean it
up, and release it to the world, I briefly contemplated using the GNU
General Public License instead, but decided not to do this.  ivykis does
not do much work itself, and the features it provides are readily available
through other means.

The power of ivykis is that it provides a useful abstraction, one that is
easily duplicated by anyone who would wish to do so.  Its value is mostly
of an infrastructural nature.  That is why I don't think that releasing
ivykis under the GNU General Public License would give the free software
community any particular advantage.


I look forward to hearing your, or any of your evaluator's opinion in
this matter.


Respectfully submitted,
Lennert Buytenhek