On Fri, 27 Mar 2015 22:37:21 +0000, weaselcat wrote: > On Friday, 27 March 2015 at 22:32:32 UTC, ketmar wrote: >> On Fri, 27 Mar 2015 16:11:41 +0000, Ola Fosheim GrÃÂ¸stad wrote: >> >>> Not a broken design. If I have to run multiple servers just to handle >>> an image upload or generating a PDF then you are driving up the cost >>> of the project and developers would be better off with a different >>> platform? >> >> but it is broken! the whole point of async i/o servers is that such >> servers spend most of their time waiting for i/o. and if you need to do >> some lengthy calculations, you either spawns a "real thread" >> and commands it to wake you up when it is finished, or asking external >> server to do the job (and wake you when it is finished). >> >> what moving fibers from thread to thread does is bringing in state >> copying (we want our threads fairly isolated, aren't we? so either >> copying, or ownership management). >> >> the whole thing of cooperative multitasking is to be... cooperative. in >> several years some Shiny New Async Framework will use "no transferring >> fibers between worker threads" as Spectacular Invention. > > as an outsider to the web-scale world, > this entire thing seems like a half-baked fork reimplementation
the whole "userspace threads" concept is a reimplementation of kernel threads and sheduling. ;-) the main question is the amount of work required to switch between threads. if we have a little amount of threads that does heavy work, it's ok to use kernel mechanics: the time of context switching is neglible. but it we have alot of threads that mostly waits for i/o, then does very little amount of work and waits for i/o again, context switching time starts to show itself. so we moving the whole "treading" thing to user application, thus minimising thread context switching time. all in all this is a half-baked kernel thread reimplementation, yes. but it has it's own pros. and cons, of course: such as unresponsive user thread can block the whole app, like in good old windows 3 times.
Description: PGP signature