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] Common IO classes
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-05-25 (19:34)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] Common IO classes
On Fri, 21 May 2004, Gerd Stolpmann wrote:

> Hi list,
> maybe you remember the discussion about common I/O classes. We (Nicolas
> Cannasse, Yamagata Yoriyuki and I) continued the thread privately, and
> agreed upon the following draft:
> Maybe other library implementors are interested in a common standard,
> and follow this draft (our hope).

I like it.

Some comments:

- 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.

- The problem with returning 0 for non-blocking I/O when no data is 
available is when someone writes:

let really_input chan str idx len =
	let rec loop idx len =
		let rval = chan#input str idx len in
		if rval < len then
			loop (idx + rval) (len - rval)
	loop idx len

Which busy waits for input.  Hmm.  Actually, this isn't a diaster, 
necessarily.  Not optimal, granted, but not a diaster.  I wouldn't have a 
problem saying "don't do that!", except I would like some way to determine 
that I'm dealing with a non-blocking channel, so I know to not do that.

- 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?

"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 

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