Yeah, Frank's approach is the one I'd use.
I did not add a Flush() because I was worried that its meaning would be
completely ambiguous.  For example, when you flush a stream which is writing
to disk, should it do an fsync() to make sure that the data actually reaches
the physical device before it returns?  In most cases, this is not what you
want, but if you don't do the fsync() then your Flush() is really only
flushing *part* of the pipeline.  How do you decide how deep the flush
should go?  In different cases, callers may want totally different things.
 There's no way for a generic interface to cover all of this.  These
questions become even more complicated when you have more layers.  For
example, if you have a stream wrapper which compresses the data, then a
"flush" could be an expensive operation since it would interrupt the
compression algorithm.

Because of all this, I think it has to be up to the caller to be aware of
exactly what it wants to flush, and to call flush directly on the streams
that need it.  Note, for example, that the CopyingOutputStreamAdaptor class
has a Flush() method with well-defined semantics; it's just not part of the
abstract ZeroCopyOutputStream interface.

In theory, CodedOutputStream itself could contain a Flush() method which
simply flushes its own internal buffers down to the ZeroCopyOutputStream
under it, but does not attempt to make that stream flush itself.  However,
it feels cleaner to me to simply destroy the CodedOutputStream and construct
a new one, which achieves the same effect.

On Mon, Oct 20, 2008 at 6:57 PM, <[EMAIL PROTECTED]> wrote:

>
> I recently ran into this problem as well.  I wrote a socket stream
> that has a flush operation.  To use it I had to do
>
> {
>  CodedOutputStream coded(&my_zero_copy_socket_stream);
>  message.SerializeToCodedStream(&coded);
> }
> // coded is now out of scope so it has back-up unused buffer
> my_zero_copy_socket_stream.Flush();
>
> I had to use coded stream temporarily to write, then call Flush() on
> the underlying stream AFTER it goes out of scope.  It feels a bit
> ugly.
>
> But then again, Flush() does not really make sense for many things,
> and having its existence in the abstract interface clouds its meaning
> (so you would have to say in ArrayOutputStream that Flush() does
> nothing.
>
> Frank
>
>
> On Oct 20, 2:37 pm, ptab <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > Why there is no Flush() operation on ZeroCopyOutputStream and on
> > CodedOutputStream? Is there any way to persist/send over network
> > whole current content of buffers ?
> > I think I would be able to provide implementation of the method for
> > most stream's implementations, but I think that it was a design
> > decision.
> > What's the reason ?
> >
> > I would like to implemented some communication over network based on
> > these
> > streams and flush operation is crucial to avoid blocking on both ends
> > of the protocol.
> >
> > Thanks,
> > Piotr Tabor
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to