[E-Lang] multithreading

[Mark S. Miller]

--=====================_121477918==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 07:13 AM Thursday 7/19/01, Jonathan S. Shapiro wrote:
>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?

Frankly, I don't understand the example.  Why isn't preempting the output 
stream between requests adequate.  Even a preemptive scheduler can't 
guarantee that anything better would happen (unless you introduce priorities 
and such).

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, I have no problem 
extending the underlying runtime & UTCB to provide "devices" that handle 
these additional cases "primitively".  Though it would be better not to have 
to extend the UTCB, of course, so I look forward to understanding the question.


        Cheers,
        --MarkM

--=====================_121477918==_.ALT
Content-Type: text/html; charset="us-ascii"

At 07:13 AM Thursday 7/19/01, Jonathan S. Shapiro wrote:

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


Frankly, I don't understand the example.  Why isn't preempting the
output 

stream between requests adequate.  Even a preemptive scheduler can't

guarantee that anything better would happen (unless you introduce
priorities 

and such).


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, I have no problem

extending the underlying runtime & UTCB to provide
"devices" that handle 

these additional cases "primitively".  Though it would be
better not to have 

to extend the UTCB, of course, so I look forward to understanding the
question.


       
Cheers,
        --MarkM

--=====================_121477918==_.ALT--