Escaping the Tyranny of the GC: std.rcstring, first blood

[Dmitry Olshansky via Digitalmars-d]

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