[boost] Re: Overlapped IO usinig IOStreams library (was: reCompressionusinig IOStreams library)

From: George M. Garner Jr. (gmgarner_at_[hidden])
Date: 2004-09-12 23:38:30

Johnathan,

>>                 character c;
>>                 while ((c = boost::io::get(src)).good() && !isalpha(c))
>>                     ;

Basically, I do not see any scenario where you would want to write a buffer 
to a modern operating system one character at a time,  more or less do so 
asynchronously.  The above quoted code needs to be buffered to be useful and 
there is no reason to write to a user-mode buffer asynchronously.  So my 
recommendation is that this particular type of filter should remain 
oblivious to asynchronous IO.

It would be helpful to think of asynchronous IO in terms of two basic 
paradigms:

1. user-mode synchronous/kernel mode asynchronous IO.

2. user-mode asynchronous/kernel mode asynchronous IO.

The first paradigm does not require any particular modification of your 
library.  As I already mentioned, I have overlapped IO working with your 
library in its current form.  The IOStreams library has no reason to know or 
care that I am blocking in user rather than kernel mode.

The second paradigm (for example, using IO completion ports) is very 
difficult to fit within the Standard Library stream and filebuf concepts. 
The logic is quite different.  To begin with read and write will need at 
least one additional parameter that encapsulates OS specific thread local 
stream state, including stream position and asynchronous io result.  Second, 
you will need some way to retrieve extended error information on a stream 
that differentiates between failure that indicates the io operation is 
pending and failure that indicates no further processing is possible. 
Sockets, DCOM and CORBA all have conceptions of extended error info on 
procedures.  Windows has GetLastError().  Exceptions might be used but they 
suck up too many cpu cycles for an error condition that is expected on 
virtually every asynchronous io operation. Perhaps you might just introduce 
an io_pending_bit into your stream state.  But I would leave the return 
value alone.  Finally, you need some way to relinquish the read or write 
buffer, and its lifetime, to the asynchronous completion port.

My current problem is that I have just discovered that your 
line_wrapping_output_filter is writing to my overlapped_filebuf one 
character at a time.  I purposely did not implement buffer in it because 
this is not thread-safe and must occur at a higher level.  I need a 
buffering filter or wrapper.

Hope this helps.

Regards,

George.