Hi, all. There's been a recent exchange on the Tor development list
about the intersection of signals with pthreads with libevent. Both
posts are (I hope) concise, so I'll link to them here:
http://archives.seul.org/or/dev/Feb-2007/msg00028.html
I'm adding support for IOCP writes.
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
I wrote:
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 :-/
As it
I wrote:
As it is, it's easy to support serial writes with IOCP, it's supporting
multiple concurrent writes which is awkward for a convenient-to-use API
over IOCP - and this I would think is absolutely required for some uses of
UDP sockets.
I've figured out a decent way of doing it, a
From: Toby Douglass [EMAIL PROTECTED]
I'm adding support for IOCP writes.
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
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
Rhythmic Fistman wrote:
I don't think you should be passing the same overlapped structure
twice to WSARecv/Send. I'm pretty sure that the overlapped isn't
yours until GetQueuedCompletionStatus says so. Try a unique
overlapped structure for each overlappable call.
Don't worry, I'm not re-using
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
Rhythmic Fistman wrote:
On 2/22/07, Toby Douglass [EMAIL PROTECTED] wrote:
Yup. I'll be passing in a struct which contains that overlapped as its
first member. When it comes back to be, I'll cast the overlapped
pointer to my struct type. I think this means though I need a malloc
per write,
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
10 matches
Mail list logo
