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 BAA27988; Wed, 26 May 2004 01:53:21 +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 BAA27650 for ; Wed, 26 May 2004 01:53:20 +0200 (MET DST) Received: from smtp.mbg.ocn.ne.jp (mbg.ocn.ne.jp [210.190.142.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4PNrIEV019445 for ; Wed, 26 May 2004 01:53:19 +0200 Received: from localhost (p30179-adsau12honb7-acca.tokyo.ocn.ne.jp [220.99.34.179]) by smtp.mbg.ocn.ne.jp (Postfix) with ESMTP id 6BE426546; Wed, 26 May 2004 08:53:17 +0900 (JST) Date: Wed, 26 May 2004 08:50:57 +0900 (JST) Message-Id: <20040526.085057.112626777.yoriyuki@mbg.ocn.ne.jp> To: bhurt@spnz.org Cc: info@gerd-stolpmann.de, caml-list@inria.fr Subject: Re: [Caml-list] Common IO classes From: Yamagata Yoriyuki In-Reply-To: References: <1085151218.30476.125.camel@ice.gerd-stolpmann.de> 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 40B3DC6E.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 caml-list:01 2004:99 cdt:99 silently:01 ignoring:01 generic:01 differing:01 api:01 non-blocking:01 non-blocking:01 enforcing:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Brian Hurt Subject: Re: [Caml-list] Common IO classes Date: Tue, 25 May 2004 14:41:34 -0500 (CDT) > - I wish that doing a read or write on a closed channel was required to > throw a known, defined, error. This makes actually catching and handling > the error possible. As it is, with every library possibly throwing a > different exception or even just silently ignoring the error it's > impossible to deal with the error. > > Note that there would still be library-specific exceptions, for > library-specific errors. But this is a generic error that all libraries > have to deal with, and thus should deal with in the same way. It was discussed. Since you can easily extend OO channels to detect these errors in you favorite way, we do not feel that it is very important to define the specific exception. One of the goal of the standard is not to require installing a specific library. This makes defining new exceptions in the standard is impossible. So what left for us are Failure and Invalid_Arg, both of which are not very useful. > - Differing from the precise semantics of the Unix API isn't evil. I'd > much rather have it be defined and precise. That way I can at least work > around them in a portable way if they don't do precisely what I want. > Which my previous example is a demonstration of, by the way. > > - Polymorphic I/O is defined as blocking, while Octet I/O may be blocking > or non-blocking. Say I'm writting a UTF8 -> UCS4 (as int) converter, > where I can read 6-7 octet to create one unicode character. How do I work > around a non-blocking octet input without busy waiting? Non-blocking IO causes the "busy waiting" problem in some layer. The non-blocking IO program should use an event-loop, which is outside of the scope of our standard. So, it seems for me now, we should make all channels blocking, and if a channel is blocked in the middle of IO, it should be considered as an error. In such a case, the channel would raise Sys_blocked_io and its state would become undefined. Recovering from such an error would be desirable, but enforcing such behavior to all libraries would technically not easy. I do not want the standard lay too much burden to the library developper. -- 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