NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kqueue design issues.

Hi, I'm having a few doubts in regard to the way how kqueue was
designed to handle multiple file descriptors.

The problem as I see it, comes from the fact that kqueue returns
event objects, rather than file descriptors.

So instead of - "here is file descriptor 5, it has READ and WRITE
events on it"

kqueue does this - "here is READ event, its property is file
descriptor 5", "here is WRITE event, its property is file descriptor 5"

This way, kqueue makes it very unfriendly to manage open file
descriptors as you step through the events array.

Here is the scenario:

I enable READ and WRITE events on a group of file descriptors and then
call kevent() to wait for events. Kevent() returns pending events in
the events array.

I step trough the events array, events[0] has READ event on fd 5. I
read data from fd 5, try to parse it and realise the client is sending
me something I cannot understand, so I close the connection and free
the connection context.

As I step through the events array, say at events[3] I find WRITE event
on fd 5. This event is in inconsistent state now, because fd 5 has been
previously closed, any context associated with that connection has been

So the question is: what am I supposed to do with this event now? If I
try to perform any system calls on it, they will return error. I need
to ignore this event, this is easy with poll() because READ and WRITE
events reside in the same object, but with kqueue I now need to have a
hash table, every time I step through the events array, I need to check
the hash table to see if this file descriptor is still valid.

Do people agree with me, or am I not getting something about kqueue?

Home | Main Index | Thread Index | Old Index