Biping MENG wrote:
Eric,
Hi!
As far as I see, the execution path of one command is much complicated
so that describing the state at any moment of the execution process is
not that easy.
I thought about the difference between these two solutions, and I
found they actually requires a same suit of things to be done, only on
different levels:
They both requires us to implement:
- How we react when a session is blocked at some socket I/Os.
- How we react when new data available on some socket is detected.
- How we resume a session.
Userland threading allows us not to worry about how complicated the
current state is; in another word it provides a low level state
management mechanism by keeping thread context. So we simply do some
context switches to do the above things:
- How we react when a session is blocked at some socket I/Os.
Swap out the context of the session.
- How we react when new data available on some socket is detected.
Add the session to the READY list.
- How we resume a session.
Swap in the context of the session.
However, a stateful execution engine requires us to implement the
state management by ourself:
- How we react when a session is blocked at some socket I/Os.
I'm thinking if the execution path is flattened, and all Socket I/O
are separated out from the execution call, in a form of something like
this:
Socket I/O read/write + Execution method call 1 + Socket I/O
read/write + Execution method call 2+ Socket I/O read/write +
Execution method call 3+ ...
then it'll be very easy for us to remember the state. A simple number
can tell us all we need.
This is actually very similar to how libdrizzle's protocol stack works.
I am proposing this, because I think there will be much more
information we need to remember if execution calls are nested, like
how deep we have went along the stack. Besides we always have to
rebuild a calling stack when the session is resumed.
But I guess it will be very hard to make the execution path flattened
if some recursive execution procedures exist.
Yes, this is a big problem.
How do you think of this flattened execution style? Do you think it is
realizable or/and worth to be realized?
Yes. It's realizable, but not something that can be done this summer :)
- How we react when new data available on some socket is detected.
Add the session to the READY list.
- How we resume a session.
For a flattened execution path, we simply choose a start point to
rerun from according to the next step number. Otherwise, we have to
rebuild the deep calling stack.
What about just pausing execution by yielding the thread's control to
the kernel using sched_yield()?
By the way, where can I get the Drizzle Protocol? I saw a proposal of
the Drizzle Protocol on the wiki page at
http://drizzle.org/wiki/New_Protocol. Is it the one we are using
currently?
No, it won't be trivial. :) We also need an event notification
system that lives alongside the scheduler plugin. When a Session
hits a potential blocking point, it will save it's state, register
an event with the event system, and return from the execution path
to the scheduler. The scheduler can then run other sessions as it
sees fit. When the event system notices the blocked session is ready
(probably a libevent callback saying socket is active), it can make a
call into the scheduler saying "run this session", where the scheduler
will then find a thread for it or put it on a list of runnable sessions
next time a thread is free. This ends up looking a lot like a typical
operating system scheduler/interrupt system.
If you haven't already, give this a read:
http://www.oddments.org/?p=49
I talk about the different parts (and the I/O layers) in more detail.
-Eric
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
