AsynchronousByteCharChannel and Timeouts
cowwoc at bbs.darktech.org
Fri Aug 7 07:58:59 PDT 2009
Alan Bateman wrote:
> cowwoc wrote:
>> Weird. Comports (and sockets too I believe!) can be treated as
>> HANDLEs in the win32 API. You can then use ReadFile(), CancelIo() to
>> read and cancel overlapped operations. CancelIo() has the limitation
>> of only being cancellable from the thread that initiated the read but
>> you can use "completion ports" to work around this limitation and
>> essentially get the Windows Vista functionality back in Windows XP.
>> That's what I'm using for comports. Couldn't you do the same for sockets?
> No, because it cancels all pending I/O operations on the handle
> (initiated by the calling thread) and so can't be used when there may be
> more than one I/O operation outstanding that was initiated from the same
> thread (meaning read and write). Furthermore, the initiating thread may
> be executing a completion handler and so may not return to poll the
> completion port in a timely manner. The CancelIoEx call introduced in
> Vista does address these limitations but we don't have any plans to use
> it. The only Vista specific feature we are using here is the new thread
> agnostic I/O so that I/O operations can be initiated on non-pooled threads.
Oops! It seems we've just discovered a bug in my code :) Fixing this is
not going to be fun :( I think what I'll have to do is reserve two
threads per channel (one for read, one for write) and use a thread pool
for handling completion handlers.
> I'm not suggesting you silently eat bytes, but rather look for a
> solution that would allow the operation to complete successfully for the
> case that bytes are transferred into the buffer at just around the time
> that the timer expires. That would be more desirable than data loss.
Any idea on how to do this?
More information about the nio-discuss