Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Flush behavior of baseic I/O class type
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] Flush behavior of baseic I/O class type
On Sam, 2004-10-16 at 19:51, Yamagata Yoriyuki wrote:
> From: David MENTRE <>
> Subject: Re: [Caml-list] Flush behavior of baseic I/O class type
> Date: Sat, 16 Oct 2004 18:26:24 +0200
> > Yamagata Yoriyuki <> writes:
> > 
> > >   1) Output as far as possible, and leave the rest.
> > >   2) raise an exception
> > >   3) undefined.
> > 
> > Or  4) call blocked until the whole buffer can be flushed.
> It may be ok for non-blocking I/O, but it will cause "busy-waiting" ,
> so perhaps a user does not like it.  Moreover, for example, if the
> channel is actually a filter, and it needs more inputs to determine
> the next output, then it will stuck forever.  (See the case of the
> multibyte charcter code converter in the previous mail)
> The easiest way (from the implementer's point of the view) would be
> 1), or 1') do the best effort to output, but nothing is guaranteed.
> However I'm afraid that it will cause a subtle I/O bug.

Which one?

We need "flush" to ensure data is actually communicated to the other
endpoint of the channel, i.e. it is a means of synchronisation. When the
data are sent in a way this synchronisation cannot be done, this feature
is used in the wrong way, and I think raising an exception would be

Well, this is why we _need_ "flush" sometimes. There may be other
situations where softer requirements suffice, e.g. when "flush" is
called for debugging purposes such that as much as data as possible are

So I think there is no general rule, it depends on the purpose "flush"
is used for.

Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: