On Fri, 2008-01-11 at 16:06 +0100, Henrik Nordström wrote: > ons 2008-01-09 klockan 21:13 +1300 skrev Amos Jeffries: > > > That this code is currently depending on that implicit guarantee when it > > should not be. This change is the perfect time to drop that implicit > > dependency and make it clean (bug free!). Having one precursor call > > schedule its successor is the cleanest and fastest way to do that. > > Run-time speed optimizations can wait, but this is a stability issue. > > Even the day when we are fully SMP with support for 80 CPU cores call > order of calls scheduled form the same job will be preserved, unless > they are explicitly made as callouts for parallell processing which I > don't see will be needed. > > To scale on SMP it's very important you keep the processing of the same > job on the same CPU. Each time data needs to cross from one CPU to the > other is very expensive, and each time you need to syncronize access for > all CPUs is really bad.. > > Ideally there will be one worker thread per CPU core, each with their > own filedescriptors, async queues, comm loop etc. Possibly even memory > management. > > It's still too early to say if this will be done using threads or > processes. But what we certainly will not see is that everything uses a > global async-call queue managed by all CPUs. If you desing that way then > you could just as well not go the SMP path and you'll probably get > better performance..
That is one of the key points of the current code in head; because the dispatch and queue mechanisms are not based on globals, you can just instantiate a new loop where that is appropriate. As long as the new stuff can be used by passing code that needs to do async calls a handle to the loop (or a dispatcher, or whatever), then this is still directly feasible. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
