---

fpoller

Overview

the fpoller library is a lightweight polling engine for Unices. It transparently manages connections, and uses multiplexing to handle orders of magnitude more simultaneous connections than is possible with one-thread-of-execution-per-connection schemes.

it is not necessary to understand multiplexing or non-blocking i/o to use this library, although it is recommended. UNIX Network Programming by W. Richard Stevens is the standard text.

Delegates

the fpoller engine will delegate to one of the new scalable polling mechanisms if one exists on the platform on which it is compiled. Right now it supports /dev/poll (available on Solaris 8, and a s apatch for Linux) and kqueue() (available on OpenBSD >= 2.9 and FreeBSD >=4.2). If neither of these are available, fpoller will use traditional poll(). Scaling with traditional poll() will be linear: kqueue and /dev/poll both offer much better scaling.

Use

poller is always a typedef to the fastest poller available. this may be basic_poller < poller_kqueue >, basic_poller <poller_devpoll >, or basic_poller <poller_generic >. traditional_poller will always be a typedef to basic_poller <poller_generic >.

the basic interface contains only three functions and is specified in basic_poller, which see. client code creates descendants of callback, which it registers with a poller expressing interest in either READ or WRITE availability. each time it gets called, a callback returns either KEEP or REMOVE , and the poller does the obvious. Generally, unless a socket is being closed, a callback will add another callback before returning remove. this is not required, however.

The usual structure of a program using the polling engine is:

define at least one reader callback
define at least one writer callback
create a poller
open a listening socket
register an accept_callback<reader_callback> for the listening socket
while (1)
. poller.poll()
. unrelated processing (if necessary)
end while

since accept callbacks usually always do the same thing, this default behavior is encapsulated in accept_callback.

similarly, the library defines read_callback and write_callback. Write callbacks are usually very much alike and therefore only take one policy template argument, which determines if the underlying file descriptor is to be closed on completion. Reading is a more involved task, so there are several policy arguments to read_callback, which see.

convenience funcs get_listen_socket, would_block and set_non_blocking are also provided.

questions, comments, bug reports, what have you --> crooney@crooney.com. go ahead, send it, i welcome all feedback.

---