[coyotos-dev] Need for revised invocation
smagi at naasking.homeip.net
Sun Feb 5 23:08:33 EST 2006
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.
More information about the coyotos-dev