[boost] Re: IOStreams formal review start

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-09-07 16:37:54

"Jonathan Turkanis" wrote:

> >  - reset stream settings, either for individual stream or all of them
> >    at once. I have no clue how generic solution may look like
>
> You can reset the state of a filter by calling close.
>
Maybe. Maybe one may like just to modify some minor property
of pipeline w/o affecting its main functionality.

> >  - 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.
>
> This would be almost easy, using flushable, since you could flush all the
> filters and connect the last one temporarily to a null_sink.
Unfortunately,
> you'd need a special function to tell the resource to discard its data.
>
I see two problems:

- the flushing may take lot of time, if some complex filters are involved,
  discarding may be required quickly-handle-error technique

- it is not really sure flush would flush: for example filter removing
   certain word may wait intil words get finished. What is flush()
   semantic of theirs?

> >  - halt temporarily/restart (for output streams only?).
> >       This action may be propagated downstream since some
> >      filters may have busy sub-threads of their own
>
> I'm not sure I understand.
>
Equivalent to putting null sink on the top of pipeline
(and maybe after each part of pipeline, if the part acts
asynchonously).

Not sure now it it is worth the troubles.

> >  - reset stream settings, either for individual stream or all of them
> >    at once. I have no clue how generic solution may look like
>
> This sounds like discard + open.
>
Not really, rather like sending SIGHUP to a Unix process.
No data loss, no open/close.

> >  - generic command/event interface for stream specific actions.
> >       E.g. using named commands/events.
>
> This might be a better approach than making the Concept interfaces fatter
> and fatter.
>
Functions like flush() etc have exact interface, well-defined names
and semantic. The event/command would be likely typeless.
I think generic functionality should be explicitly exposed and the rest
could be handled by commands.

> >  - generate string description of what is in stream chain
> >     (like stream::dump() for debugging)
>
> The character sequences, or the filter/resource sequence?
>
The latter. E.g. for to print debug into on console.

> >  - serialize/deserialize whole stream chain
> >    (deserialization would open files/memory mappings,
> >     do seek, restore caches, whatever is feasible)
>
> Great! If you are volunteering to implement it ;-)
>
Well...it was just an idea.

> > 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.
>
> Could you elaborate?
>
Example which throws (and exception gets caught and handled),
example which sets failbit or whatever and how it could be handled.

/Pavel