Hi Biping, On Thu, May 14, 2009 at 11:33:49AM +0800, Biping MENG wrote: > So, we've been going down the path of own userland thread context > switching here, but there is still the option of trying to make the > execution engine stateful for non-blocking I/O and non-blocking event > triggers (for wrapping locks). To be honest I'm not sure which is > easier, but the non-blocking execution engine will most likely be more > portable, easier to debug, and can be done incrementally. Just wanted > to point out we have at least two directions we could go in here. > > Good timing of reminding. > It rather seems more natural to make the execution engine fully stateful, > since we already had a partially stateful engine with which we can tell > state by monitoring the socket FDs. > I guess we have to do a similar work of transferring to non-blocking > socket I/Os. Besides, we also need a new state_changed call back entry so > that session could notify the scheduler when its state has changed. It's > not a so advanced task to add state to the execution process, but takes > effort really. I've got a question here. As the scheduler detected a state > change of some session, say, the currently running session is blocked on > socket I/O, thus its state changed into BLOCKED, how could we let its host > thread to stop severing it suddenly and choose another session to process? > I mean, I guess we may need much more info to describe the state of > session rather than a single flag like BLOCKED so that we can successfully > restore the session when it gets ready to go. Besides how do we do stop > severing at some point of the code path suddenly? It seems not so easy as > content switch does.
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
