From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA21406; Sat, 16 Oct 2004 20:29:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA21933 for ; Sat, 16 Oct 2004 20:29:54 +0200 (MET DST) Received: from smtp.mbg.ocn.ne.jp (mbg.ocn.ne.jp [210.190.142.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i9GITrjS030349 for ; Sat, 16 Oct 2004 20:29:54 +0200 Received: from localhost (p10137-adsau08doujib4-acca.osaka.ocn.ne.jp [221.190.0.137]) by smtp.mbg.ocn.ne.jp (Postfix) with ESMTP id 9D61E44FC; Sun, 17 Oct 2004 02:52:15 +0900 (JST) Date: Sun, 17 Oct 2004 02:51:48 +0900 (JST) Message-Id: <20041017.025148.11606687.yoriyuki@mbg.ocn.ne.jp> To: dmentre@linux-france.org Cc: gerd@gerd-stolpmann.de, caml-list@inria.fr Subject: Re: [Caml-list] Flush behavior of baseic I/O class type From: Yamagata Yoriyuki In-Reply-To: <87brf2tyrz.fsf@linux-france.org> References: <20041017.005256.41640390.yoriyuki@mbg.ocn.ne.jp> <87brf2tyrz.fsf@linux-france.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 417168A1.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 yamagata:01 yoriyuki:01 yoriyuki:01 dmentre:01 caml-list:01 2004:99 yamagata:01 buffer:01 non-blocking:01 multibyte:01 bug:01 flush:01 flush:01 writes:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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. -- Yamagata Yoriyuki ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners