Rhythmic Fistman wrote:
From: "Toby Douglass" <[EMAIL PROTECTED]>
If that's actually untouched, I could use it for my own purposes. The
alternative is probably a malloc() per write operation :-/
You shouldn't have to touch that stuff. What are you trying to do?
Keep state on a per read/write basis. Currently I keep state on a per
socket basis, but that's not enough to let you know which of an
arbitrary number of writes has just completed.
However, I'm not going to use the abovementioned rather awful method
(which I only considered from lack of alternatives) because I'm going to
hijack the OVERLAPPED pointer, which is the right way to do this (or the
least wrong way).
Issuing simultaneous asynchronous reads and writes on socket is a tiny bit
rare and special.
I agree, but there are so many possible users people are going to want
to do it. Also, it's common enough I think - HTTP with keep-alive, you
could want to implement that using async IO for both the read and the
write on the socket.
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?
That's a wider question. I'm simply implementing a dead-easy-to-use API
on IOCP.
The unixy case is trickier - I think only kqueues can handle two separate
read/write readiness requests being queued up in separate invocations.
With all the other interfaces (epoll, event ports, select) you can
request read AND write readiness notification, but you have to do
with the one system call (the select interface makes this obvious,
the other less so).
UNIX, I know nnnnnnnnnnnnnnnnathing. Well, not quite true, I know POSIX
somewhat, but true enough here for the better IO mechanisms.
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
