apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject [RFC] apr_pollcb api?
Date Sun, 19 Mar 2006 18:29:52 GMT
I haven't been happy with our apr_pollset api for awhile.

Most of the frustration revolves around how the API requires that data 
is copied from the user, and we therefore have to manage it, keep track 
of it, and recycle it.

This means we added ring structures to track the data, and then we added 
optional mutexes to make it all thread safe.....

The ring structures also mean we must iterate them for _delete() and 
_poll(), wasting more cpu time.

So, I would like to propose a new poll API, I am initially calling 
'apr_pollcb'.  I am not stuck on the name, and better suggestions are 
welcome :)

Basic Concept:  You _add() a whole bunch of sockets, Calling _poll(), 
you pass a callback function.  This callback function is called with the 
same pollfd you used in _add(). (pollfd contains a user_data baton).

The pseudo API:

enum apr_pollcb_type_e {
#if HAS_KQUEUE
    APR_POLLCB_KQUEUE,
#endif
....
    APR_POLLCB_DEFAULT,
};

apr_pollcb_create(apr_pollcb_t **pollcb,
                   apr_pollcb_type_e ptype,
                   apr_pool_t* pool);


apr_pollcb_add(apr_pollcb_t *pollcb, apr_pollfd_t *descriptor);

apr_pollcb_remove(apr_pollcb_t *pollcb, apr_pollfd_t *descriptor);


typedef int(*apr_pollcb_cb_t)(void* baton, apr_pollfd_t *descriptor);

apr_pollcb_poll(apr_pollcb_t *pollcb,
                 apr_interval_time_t timeout,
                 apr_pollcb_cb_t* func,
                 void* baton);


Positives:
- O(1) Insertion & Deletion for epoll/kqueue/eventports
- O(n) iteration of results for epoll/kqueue/eventports
- No memory allocations inside the API. No copying of the user data.
- No lame limits on the number of sockets you can add or get data about 
in on call.
- If KQueue is broken on your platform, you can at runtime select poll() 
or select(). (I believe it would like similar to how process mutexes 
work underneath.)

Negatives:
- Users of the API must maintain the lifetime of the apr_pollfd_t structure.
- Poll/Select Implementations will likely need to keep extra state, and 
copy user data, and maybe even need mutexes to remain thread safe.

Questions:
- How could win32 fit into this type of API?  It would be awesomr if we 
could ditch select() on win32.

Thoughts?

-Paul

Mime
View raw message