[E-Lang] multithreading

[Bill Frantz]

At 7:13 AM -0700 7/19/01, Jonathan S. Shapiro wrote:
>    In the context of the multithreading discussion, I  want to point out
>that there are things that can't really be done *without*  preemptive
>multithreading, and that some of them are a damned nuisance. We're
>running into a few of these in the EROS work right now.   The most obvious
>is flow control on full-duplex  streams. You have an input stream and an
>output stream, and the input stream  needs to be able to preempt the
>output stream when XOFF arrives. I think it's  worth noting that E relies
>on the underlying runtime to hide certain types of  underlying asynchrony
>(like this one).   Hmm. I was going to write a longer note, but I see
>that time has gotten away from me. Here is the challenge question: how
>should  full-duplex streams be managed in E?     Jonathan

I know of two basic ways full duplex streams are handled.  Let's call them
the UART way, and the TCP way.

The basic logic of the UART way is that the handler gets an interrupt
(message) saying that either the transmit buffer is empty, or that there is
a character in the receive buffer.  It then does:

If there is a character in the receive buffer, read it.  If it is a XON set
isSendOK = true.  If it is a XOFF set isSendOK false.  Otherwise place it
in the (software) input buffer.

If the input buffer is getting full, make a XOFF the next character to be sent.

If the transmit buffer is empty, and isSendOK, and there is a character to
send, send it.

Whenever the input buffer nears empty, and a XOFF has been sent, send a XON.

I think this kind of logic maps to E without much difficulty.  The big
issues are how the input buffer gets emptied and the output buffer gets
filled.  It probably makes most sense to have another call on the object
which fetches characters from the input buffer.  There also needs to be a
way of delaying the programs filling the output buffer, but the E
asynchronous send provides a natural way to implement delay.


The TCP way, which has many variants including the one used in Tymnet,
involves each end knowing how much it can send before it receives some kind
of signal from the other side.  This kind of logic allows reasonable
efficiency while still limiting memory usage.

Note that the E data communication system assumes infinite size buffers.
We probably should consider some flow control to help limit denial of
service attacks.  There may be a can of worms here though.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA