On Sat, Apr 19, 2008, Henrik Nordstrom wrote:
> I don't remember why comm_close was made async, but the more I think
> about it I think it's most likely wrong. comm_close SHOULD invalidate
> any pending comm operations on that fd, anything else just leads to
> nightmares.
The back-end of comm_close() may have to be async to properly support
windows overlapped IO in the future. You have you cancel pending IOs
which IIRC may actually fire before the cancel can be processed. Its been
a few years since I toyed with overlapped IO so I can't be sure.
Someone with more Windows Overlapped IO experience should chime in.
Also, I reckon it would be a smart idea to sit down and code up some
very basic Windows overlapped IO examples (like a tcp proxy! :) to
properly explore its behaviour before any changes to comm are made.
(Thats what I'll be doing before my comm changes in the cacheboy branch,
as I really don't want to use libevent/libev's "windows" mode for IO.)
Adrian
-- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -Received on Tue Apr 22 2008 - 13:15:54 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT