Subject: Re: [e-lang] EIO: Proposed a non-blocking I/O library for E

From: Mark Miller <markm@caplet.com> · Date: Thu, 05 Dec 2002 20:50:09 -0800

At 01:26 PM 12/1/2002 Sunday, Dean Tribble wrote:
>Some suggestions:

I'll be meeting with Dean and a few others tomorrow, where I expect we'll 
discuss EIO. Afterwards I'll explain in more detail my take on these issues.  
So a here are a few quick notes before the meeting changes my mind about 
everything ;).

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

I started with "EStream", but it made the writing awkward. A stream is what 
flows through an EReader or EWriter.   In fleshing out the metaphor, it's 
clear that an EReader or EWriter is a connector at the end of a piece of 
plumbing (like a pipe) though which a stream flows.

Nevertheless, EIOConnector is too long, and EStream is more like 
conventional usage, so we may go back to it. 

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

Java doesn't have any one terminology convention that I know of that applies 
to characters, bytes, and object  (reference)s, so I don't know of a choice 
that would be both conventional and less confusing.  (InputStream / 
OutputStream is specific to bytes.)

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

Agreed, I will fix this. 

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

Agreed. Done. 

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

Agreed. Done. 

>- The material in "http://www.erights.org/elib/concurrency/eio/goals.html" 
>should be in the package doc.

Nah, that's what a web site is for, especially since these are more goals 
than specs.  But the package doc links directly too it. 

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

Almost certainly, but I want to postpone sugar until we've lived directly 
with the primitives for a little bit. 

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

I assume by "start" you mean an element to look for rather than a position?   
(If you mean a position, that's the peek we've already got.)

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

This is the big issue. By normal E design criteria, and from the currently 
posted material, my whenAvailable semantics seem obviously bad.  They may in 
fact be bad, but to explain what I'm trying to do deserves a long 
message. Whether or not I will still think it's a good idea after the 
meeting, I will try to write this long message so we can learn from it one 
way or another.

----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang