From: Dean Tribble <>
Replying To: Mark Miller <>
Date: Sun, 01 Dec 2002 13:26:45 -0800
Subject: Re: [e-lang] EIO: Proposed a non-blocking I/O library for E

Some suggestions: markm 

- Rename EIOConnector to EIOStream since it describes what is in common 
among read and write streams? markm 

- Keep consistent with Java naming convention, so Reader and Writers should 
be for handling text, not raw streams  (note that I like the use of the 
Reader and Writer terminology, but it's not worth the confusion). markm

- In EIOConnector, the description:  "You use an EWriter to place elements 
into a stream,  and you use a downstream EReader to obtain elements from the 
stream." is from the point of view of a program constructing a pipe.  Most 
stream usage in my experience is either one0sided (e.g. file streams) or 
transformers (read from an input stream, do something to it, write on and 
output stream).  Pipes are sufficiently uncommon in usage that I think it 
is a confusing focus for description (this is just an explanatory issues, I 
think). markm

- UnavailableException should be a kind of IOException so that if I want, I 
can just catch IOException.   Needing to handle two kinds of exception if 
all I want to do is crash will be annoying. markm

- The second sentence of the EWriter.flush() documentation  ("A flush() 
operation obligates all elements") is a much 'javadoc' better summary, and 
should be the first sentence. markm

- The material in "" 
should be in the package doc. markm 

- need to add read(amount) and read() markm 

- need to add peekOne(start) which peeks ahead that many 
characters.   Otherwise I suspect making a line-reader is very expensive 
(this could be refuted with an inexpensive line reader that has all the 
right properties). markm

The big issue is the semantics of whenAvailable.   I generally like the 
interface, but I think it is a bad idea to have the waiter on whenAvailable 
be invoked in the same turn.

- It introduces concurrency issues between the writer and the reader of a pipe
- It has different semantics within a vat than between vats 
- It It makes the whenAvailable() operation sometimes immediate, sometimes 

If those issues aren't compelling, I'm sure I can come up with more....  :-)

A secondary issues is whether there can be multiple waiters.   I think there 
should be, but I think that will fall out one way or the other once the 
whenAvailable semantics are fixed. markm


e-lang mailing list