On Thu, Feb 22, 2007 at 12:09:18AM +0100, Rhythmic Fistman wrote:
> Issuing simultaneous asynchronous reads and writes on socket is a tiny bit
> rare and special. Are you sure that's what you want to do? If so, great -
> io completion queues can handle it. Bu-ut if libevent was modelled on the
> unix
> select-style interfaces, most of which don't easily support this kind of
> thing,
> how is this situation cropping up, assuming that this is just an IOCP port
> of libevent?
Almost all of my use of libevent involves simultaneous reads/writes, for
relays which filter streams on-the-fly, in both directions. It was tricky at
first, but over the course of several revisions it all settled out.
*sigh* Someday I'll have to muster up the energy to change the name, because
on this list its just damn confusing, but my buffered-IO implementation is
in libevnet:
http://www.25thandclement.com/~william/projects/libevnet.html
Specifically, see src/bufio/socket.c and the functions
bufio_socket_event_run
bufio_socket_event_mod
bufio_socket_event_del
bufio_socket_event_add
bufio_socket_poll_handler
bufio_sink_poll_handler
Cancellations were tricky. Also, what I fail to see in most async libraries
is logic to handle re-entrancy from recursive callbacks. That's what the
FRAME_PUSH/FRAME_POP calls are all about. evdns.c fails in this respect,
last time I looked, as does c-ares; they'll just segfault. My lookup API,
built around c-ares, works around the c-ares problem w/ what I consider an
abysmal hack; I'm looking to maybe fork the guts into libevnet because my
re-entrancy patches were rejected. Anyhow, lookup.c does much, much more
than c-ares, ADNS, or evdns, combined.
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkey.org/mailman/listinfo/libevent-users
