22-Sep-2014 13:45, Ola Fosheim Grostad пишет:
Locking fibers to threads will cost you more than using threadsafe
features. One 300ms request can then starve waiting fibers even if you
have 7 free threads.
This statement doesn't make any sense taken in isolation. It lacks way
too much context to be informative. For instance, "locking a thread for
300ms" is easily averted if all I/O and blocking sys-call are managed in
a separate thread pool (that may grow far beyond fiber-scheduled "web"
thread pool).
And if "locked" means CPU-bound locked, then it's
a) hard to fix without help from OS: re-scheduling a fiber without
explicit yield ain't possible (it's cooperative, preemption is in the
domain of OS).
Something like Windows User-Mode Scheduling is required or user-mode
threads a-la FreeBSD (haven't checked in a while?).
b) If CPU-bound is happening more often then once in a while, then
fibers are poor fit anyway - threads (and pools of 'em) do exactly
what's needed in this case by being natively preemptive and well suited
for running multiple CPU intensive tasks.
That's bad for latency, because then all fibers on
that thread will get 300+ms in latency.
E-hm locking threads to fibers and arbitrary latency figures have very
little to do with each other. The nature of that latency is extremely
important.
How anyone can disagree with this is beyond me.
IMHO poorly formed problem statements are not going to prove your point.
Pardon me making a personal statement, but for instance showing how Go
avoids your problem and clearly specifying the exact conditions that
cause it would go a long way to demonstrated whatever you wanted to.
--
Dmitry Olshansky
