On 12/11/06, Toby Douglass <[EMAIL PROTECTED]> wrote:
Kevin Sanders wrote:
> The lesson here is you don't want the IOCP threads doing anything
> except issuing async IO, popping completions and a quick state machine
> change (see below) and issue another async IO if needed. If more
> processing is needed, put a work item in a queue for another thread to
> process. That work thread can call your state machine callback when
> it is finished, and that may in turn cause further async IO.
True. But you realise in the code I've written the IOCP threads are
internal to the library itself - the user doesn't see them or touch
them. All they do is call GQCS. If the user did blocking writes, they
would be outside the IOCP mechanism and they wouldn't be using the IOCP
threads.
I haven't looked at you're code yet, sorry I don't know the function
names. I'm referring to when the IOCP thread calls GQCS and sees the
read completion, it calls a read completion callback I believe? If
someone made a blocking call from this callback (the callback is
running on the IOCP thread) then that would be bad (performance wise).
So the IOCP threads aren't totally internal because they run the
callbacks. Unless these IOCP threads are just triggering an event
somewhere that the user threads are waiting on (please say no)?
Kevin
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
