Re: [Caml-list] Common IO classes

[Yamagata Yoriyuki <yoriyuki@mbg.ocn.ne.jp>]

From: Brian Hurt <bhurt@spnz.org>
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