From: "Christopher Baus" <[EMAIL PROTECTED]>
> Has there been much interest in an IOCP port for libevent? I would > certainly be interested. > I even started working on a rough port, but as mentioned IOCP is proactive > rather than reactive, > (ie you tell it how much to read/send and the event tells you that) and it > got rather awkward pretty quickly.
In libdemux, the event library used by felix (felix.sf.net), I modelled the problem with "control blocks" (accept, connect, read, write, AcceptEx, ReadFileEx, TransmitFile, ecc) that contained their args, a start method and a finish callback. The control blocks interacted with the event source (select, epoll, iocp, evtports, kq, no signal stuff, setting sig masks is a pain and no aio_* interface yet cos it's not that compelling), associating themselves either via "start" (unix) or the constructor itself (win32/iocp). It works well, despite the above annoying difference which is probably a wrinkle inherent in the difference between "reactive" and "pro-active". There are threadsafe and non-threadsafe versions of the reactors (which I call demuxers, echoed by asio, so I guess I wasn't completely on drugs when I made that name up) and self pipe classes for those who like to exit multithreaded apps or get attention in a polite manner. I'm not happy with the win32 self pipe as it's not anonymous (anon pipes don't work with IOCPs, socketpair doesn't exist, AF_UNIX is unimplemented, inventing a pair by connecting to localhost raises the hackles of firewall software and so on), hence I need a way of uniquely creating named pipes or to find some flag that limits the scope of the named pipe. Unfortunately, I don't know much about windows. The license is FFAU (free for any use) so if anyone's interested, steal away! Of course I'd be interested in any bug fixes (including understanding the kq workaround) and grand demuxer unifying theorems. Suggestions on how to improve the timer events are also welcome (timer queues on win32 and timed cond var on unix, I think the interface I used in the latter renders it a bit naf). Be aware that the srcs have been made "literate" and so exist in a single file: lpsrc/flx_demux.pak and require one or two config style macros (existence of various event APIs, sock_addr_len type and other stuff that's easy to guess).
The slickest implementation I've seen that works with *nix non-blocking I/O and Windows IOCP is boost ASIO http://asio.sourceforge.net/. Instead of modeling reactive behavior with IOCP, it mimics proactive behavior on *nix. It works out surprisingly well.
Wow, that looks very complete and mature, even if the name does strike fear into the hearts of australians. There's even a self pipe class for unix... but I don't see a win32 version.
From: William Ahern <[EMAIL PROTECTED]> I'm privy to my own [C] library which does this and more. Still, I don't think this necessarily belongs in libevent. libevent is popular because it does cross-platform event _polling_ very well, in a clean and simple interface.
It polls? I thought the whole point of event interfaces was to avoid "polling" readiness, preferring instead "knowing", however unix style evt interfaces fall down a little in this respect, and offer only "suspecting", still, saves CPU.
Integrating compound (higher-level) asynchronous actions like this is still a very fluid area. Take the recent DNS support in 1.2. It's probably going to follow the same tired path that c-ares, ADNS and UDNS have... slow and abortive patches for IPv6, SRV, CNAME, et al (granted UDNS has probably done the best out of all of them).
Sure, once I'd covered basic socket readiness, file io and so on, I looked to DNS thinking there would be a similar readiness interface. There wasn't, instead existing various blocking implementations where you can either wait or spawn a thread to wait for you. That kind of wrapping seemed trivial and for similar reasons I didn't wrap aio_*, because the impls that I saw seem to be pthread+blocking read/write... In any case, most overlapped=IOCPable stuff in windows seems quite low-level, lower than DNS, which is basically a socket application rather than a fundamental io operation.
libevent fills in its niche almost perfectly. If it starts to spill out all over the place things will only get messier; libevent originally made things cleaner. Maybe it's inevitable... I suppose that's how fluid areas become well trodden ground.
Covering IOCPs isn't so hard nor polluting with the following interface: unix: demuxer d; control_block_x cb(args); // override "finish" to customise behaviour d.start(cb); d.wait(); win32/iocp: demuxer d; control_block_y cb(d, args); // override "finish" to customise behaviour d.start(); d.wait(); RF _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
