AsynchronousByteCharChannel and Timeouts

[cowwoc]

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?

Gili