On 5/10/09 4:47 PM, Eric Day wrote:
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.
Have you tried linking to the portable GNU Pth? It provides a API emulation for POSIX thread and also hooks socket i/o functions, etc...
Regards, -- Davi Arnaut _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
