[boost] Re: IOStreams formal review start

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-09-06 02:13:48

"Jonathan Turkanis" wrote:

> > Would it make sense to have Discard concept which would discard
> > whatever cached data the streams may hold?
>
> I'm starting to think it would be very useful to have a Flushable concept,
which
> would allow components to advertise that they can send all buffered data
> downstream at any time. I haven't given it much though yet, but I think it
would
> allow OuputFilters to be inserted and removed in the middle of processing
a
> character sequence, as Dietmar suggested.
>
>
I can think about following concepts (interfaces) for streams:

 - close (does flush for output streams)

 - flush any caches (for ouput streams)

 - discard any cached data

     E.g. streams are used to send data to radio link.
     If problem in airspace is detected, current transmission
     is stopped, unsent data thrown aways, jamming sequence
     tramsitted and then normal transmission will continue later.

     For InputStreams one may seek N bytes ahead in file or skip
     next N bytes from socket. I don't know if this can be propagated
     in chain.

 - halt temporarily/restart (for output streams only?).
      This action may be propagated downstream since some
     filters may have busy sub-threads of their own

 - reset stream settings, either for individual stream or all of them
   at once. I have no clue how generic solution may look like

 - generic command/event interface for stream specific actions.
      E.g. using named commands/events.

I could invent more exotic functionality, e.g.
 -  bypass a stream in chain temporarily (I have no use case for it)
 - replace stream X (anywhere/first occurence within chain) for stream Y.
      This would require unique identification of X
 - generate string description of what is in stream chain
    (like stream::dump() for debugging)
 - serialize/deserialize whole stream chain
   (deserialization would open files/memory mappings,
    do seek, restore caches, whatever is feasible)

The dreaming got me an idea: streams used for testing
may generated data as function of time, e.g. simulate slow sinusoid wave.
Maybe an example of InputStream doing this could be added
as starting point for experimenting.

There's  one more stream that could be added into library:
thread-bridging stream. It would simply transfer data across
thread boundary.

There could be also example of how to handle 'buffer overflow'
errors e.g. when writing into full socket or time series generated
too fast to be read. Something a user can look at, learn and use
without need to dig into Standard.

> Input and output are usually very similar, but in this case there doesn't
seem
> to be a suitable concept corresponding to Flushable for input sequences.
True,
> one could discard data that had been read in advance for efficiency, but
is that
> what users would really want? Ideally, one would want each component in
the
> chain to put back the buffered data. This sounds like it might be
possible,
> until you realize that some of the data would have to be 'unfiltered'
before it
> could be put back.
>
The 'unfilter' sounds as impossible.

I feel InputStreams should stay simpler. OutputStreams
often need to be rather sophisticated.

/Pavel