On Fri, May 08, 2009 at 11:44:43AM +0800, Biping MENG wrote: > Stewart has also been looking at using fibers here (usserland > threads) where Drizzle would essentially have it's own userland > threading library. This would allow a scheduler to switch between > "threads" when they are blocking, allowing us to avoid making the > query execution code stateful. I'll let him comment more on this. :) > > That is a smart way of doing that. :) But I have a question. So we will do > the threads switches other than drop it to OS? Is that means we need to > make the switch more efficient than OS does? Otherwise it seems this way > of implementation of pool of threads is quite the same with multi-thread > scheduling with the only difference lying on WHO does the context switch? > Not sure if I got your meaning right.
The drizzled process (scheduler plugin) would be the one doing the context switching. This would make it more efficient because drizzled has better context of when to switch, and you don't have the jump to kernel space. There are obviously some drawbacks here, and the issue of how portable this will be, but Stewart thinks it will be doable. Stewart, want to add anything? :) -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
