AsynchronousByteCharChannel and Timeouts

[Alan Bateman]

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.

> :
>     While this is true on a higher level, I can't assume that all 
> serial protocols will have error detection/correction and users would 
> probably refuse to use a library that silently eats bytes ;) At the 
> very least I would need to make such failures more explicit.
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. If 
you do have data loss, and you do allow the application to read again 
from the channel then you are dependent on the high-level protocol to 
recover. Clearly data loss with a stream connection is more fatal.

-Alan.