[E-Lang] multithreading

[Jonathan S. Shapiro]

>> 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...
>
>Frankly, I don't understand the example.  Why isn't preempting the output
>stream between requests adequate....?

When hardware flow control is asserted on a serial wire, the other side is
saying "my input buffer is full, further characters are likely to be
dropped." There is a necessary speed of light delay in the signal
propagation, but once recieved, the transmitting serial device is expected
to stop immediately.

Note that this behaves differently from software flow control (XON/XOFF) --
I used a bad example.

So the problem is that the writer has said "write 4 Mbytes of crud" and the
receiver says "turn off the fire hose so I can swallow, you idiot!"

It clearly won't work to wait until the whole 4 Mbytes has been transmitted.

The solution in practice is to have the thread of control on the "up" side
set a marker bit, and have the thread of control on the "down" (outbound)
side proceed one byte at a time, checking the marker bit regularly after
each byte.

>In any case, if there are only a few rare general purpose cases such as
this
>one that can be absorbed into a reusable abstraction...

Streams do in general appear to be such a case. The system designed is faced
with two bad choices:

1. Assume that infinite buffering is available. If this is available, then
flow control can largely be ignored as a wire-level artifact.

2. Assume that memory is finite. If this assumption is made, then the
listener needs a way to signal the sender to hold off. This appears to
require preemptive multithreading.

I tend to prefer architectures that at least *allow* the second assumption,
since I believe it is important to offer the programmer the opportunity to
support real-world conditions if they are willing to work hard enough.
Better still, of course, is to make reality natural and easy, but the
necessary changes to the design of reality are often difficult... :-)


Jonathan