On Mon, May 11, 2009 at 05:40:16PM +0800, Biping MENG wrote: > So, the advantage of letting drizzled to do context switch briefly lies on > two facts: > - Drizzled has more knowledge to decide when and where to switch context > so as to avoid unnecessary switches.
Yup, more useful context in drizzled than letting the kernel decide when. > - We are able to do it at lower overhead (both CPU time and memory). > We should make a user level thread to yield, when it gets blocked on > locks, condition vars or I/Os. So we should use pthread_mutex_trylock on > mutex, pthread_cond_timedwait on condition vars and non-block socket on > I/Os. Well, maybe not everywhere. Initially doing it on socket I/O would be a big win, and then eventually on disk I/O. We may need to on the mutexes to prevent deadlocks (depending on the lock), but most mutexes should be pretty short lived, so we may want to always switch on those. > And add a yield(Session*) entry to the scheduler interface so that > the session running on a user level thread could yield when failed to get > a lock or read data from a socket fd. Changing the socket to non-blocking > would be a big work as we have to modify the current I/O working mode. This shouldn't be too much work, since all the socket I/O code is now abstracted and I'll be pluggin the new libdrizzle in shortly (which is all non-blocking I/O). > It seems the work will be concerning badly on I/Os of Drizzle which is > quite new to me. Any suggestions on getting familiar with drizzle I/Os > quickly? Check out the Protocol plugin interface, right now the only plugin that uses it the oldlibdrizzle. This will be going away very soon, and the new libdrizzle at lp:libdrizzle will have a plugin to replace it. -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
