From: "Toby Douglass" <[EMAIL PROTECTED]>
>> I've realised, though, that if you issue a write on a socket which
>> currently has an outstanding reading, when the IOCP completes, you don't
>> immediately know which operation has completed.
>
> Obviously I used the completion key.
Actually, that's wrong.
On a related note, did someone say that the event handle in the overlapped
structure used by the IO functions (ReadFile, etc) is not actually used?
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?
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?
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).
--
felix: lightweight threads, HOFs and game scripting.
svn co https://svn.sourceforge.net/svnroot/felix/felix/trunk felix
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
