Closed orph closed 12 years ago
lthreads run on the lthread scheduler's shared stack, I prefer not to resume it on a different lthread scheduler stack to maintain proper stack pointer arithmetic. There is an exception to that in lthread_compute_begin()/end() but I like to think about this as a special case.
Aside from lthread compute schedulers for lthread_compute_begin()/end(), lthread lib tries to stay away from using pthread and relying on it.
Understood. It's just suboptimal if I'm writing a scalable web server using lthreads. I'd create an lthread stack per CPU and then try to choose the less used lstack to handle new requests. But this doesn't deal with hotspots, so one pthread/cpu could be very busy while the others idle.
You can have listeners/CPU listening on the same fd, and the free scheduler will be the first to pick it up.
It would be useful to not choose the pthread an lthread is bound to ahead of time, but rather have the lthread resume running on whichever pthread is least contended.