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. 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. How do you think of this flattened execution style? Do you think it is realizable or/and worth to be realized? - 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. 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 > -- Cheers. Biping MENG Natural Language Processing(NLP) Lab Dept. of Computer Science and Technology Nanjing University _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
