[Libevent-users] Re: IOCP writes

[Toby Douglass]

Rhythmic Fistman wrote:
>> From: "Toby Douglass" <toby.douglass at summerblue.net>

>> 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.