[coyotos-dev] Need for revised invocation

[Sandro Magi]

Jonathan S. Shapiro wrote:
> On Sun, 2006-02-05 at 19:32 -0800, Charles Landau wrote:
> 
>>I am talking about preempting (interrupting) a happily-executing user 
>>thread by storing its program counter and perhaps stack pointer 
>>somewhere and forcing execution to go somewhere else.
> 
> 
> Wouldn't it follow that there should be a single *kernel* thread as
> well, and that the kernel should also avoid preemption?
> 
> I think the argument must not rest on whether the preemption is
> conducted at user level or at kernel level, but on whether the mechanism
> is in sufficiently "clean" to avoid inviting error. Preemption is both
> necessary and inevitable.
> 
> In my opinion, there are three possible models of Coyotos application:
> 
> 1. Purely blocking.
> 
> This is the traditional keykos/eros/capros model, and it can be
> implemented in Coyotos straightforwardly. The activation handler
> implements only "trivial" preemption -- by which I mean that all
> activations immediately resume the blocked thread.
> 
> 2. Event-loop driven.
> 
> This is essentially the model of E. The activation handler in this case
> enqueues the incoming request/event/whatever and resumes the current
> user thread of execution. The thread of execution itself operates in an
> event loop.
> 
> To my mind, this remains conceptually within the space of clean and
> maintainable designs, but offers greater options for latency management
> through asynchronous I/O and interaction.

I was puzzling over this as well. Many on this list favour event-loop, 
asynchronous-style designs, which didn't seem to jive with the a 
negative view on asynchronous IPC design. Thanks for clarifying.

Sandro