I'd like to know how it disagrees.
I believe rtsig requires you to tweak your I/O code in three ways:
1. you need to pick a realtime signal number to use for an event queue
2. you need to wrap your read()/write() calls on the socket with code
that notices EWOULDBLOCK
3. you need to fall back to poll() on signal queue overflow.
For what it's worth, my Poller library takes care of fallback to poll
transparantly, and makes the EWOULDBLOCK stuff fairly easy. I gather
from the way you quoted my previous messsage, though, that you
consider rtsig too awful to even think about.
> I haven't played with /dev/epoll yet, but I pray it is nothing like rtsig.
Unfortunately, it is exactly like rtsig in how you need to handle
EWOULDBLOCK.
> Basically what we need is, something like poll() but not so nasty.
> /dev/poll is okay, but its a hack. The best thing I've seen so far, but
> it too seems to take the idea so far is FreeBSD's kqueue stuff(which
> Hybrid-ircd handles quite nicely).
Yes, kqueue is quite easy to use, and doesn't require the gyrations
that rtsig or /dev/epoll require. The only thing that makes rtsig or /dev/epoll
usable are user-space wrapper libraries that let you forget about the
gyrations (mostly).
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/