From: miguel s. <mig...@gm...> - 2008-08-28 23:37:49
|
Alexandre Ferrieux wrote: > On 8/29/08, miguel sofer <mig...@gm...> wrote: >>> Alexandre Ferrieux skrev: >>>>> Also, from time to time people hint at the fact that passing a >>>>> continuation or coroutine across the thread/interp boundary would be >>>>> Overly Cool, but again I'd like a few examples of what real problems >>>>> this would solve. >> Scenario: webserver on a multicore cpu, one-coroutine-per-session. Ie, >> maintain session state in the coro's local vars (as opposed to hitting a >> database or something equivalent). >> >> The way it is today, you may run as many threads as you have cores (or a bit >> more), and allocate user sessions to the threads on creation in order to >> balance the load. But once created, a session has to be resumed in the same >> thread each time a new request comes in. >> >> If the coros could be resumed in any thread, you could balance your load >> dynamically - each time a request comes in. > > Oh, so you want to pack a full coro's context (including an army of > globals) into serialized form and make it migrate to the random thread > chosen, instead of just waking up the proper thread after a simple > lookup ? Either you're kidding or I'm missing something > elephant-size... Nope - if someone wanted to make things work according to that scenario, my coroutines will not support her. It would be "Overly Cool" but it does not seem likely to happen anytime soon. |