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

[Ola Fosheim Grostad via Digitalmars-d]

On Monday, 22 September 2014 at 19:58:31 UTC, Dmitry Olshansky 
wrote:
> 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).

If you porocess and compress a large dataset in one fiber you 
don't need rescheduling. You just the scheduler to pick fibers 
according to priority regardless of origin thread.

> 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.

Not really the issue. Load comes in spikes, if you on average 
only have a couple of heavy fibers at the same time then you are 
fine. You can spawn more threads if needed, but that wont help if 
fibers are stuck on a slow thread.

>> 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.

If you in line behind a cpu heavy fiber then you get that effect.

>> 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.

Any decent framework that is concerned about latency solves this 
the same way: light threads, or events, or whatever are not 
locked to a specific thread.

Isolates are fine, but D does not provide it afaik.