How many std.concurrency receivers?

[Charles Hixson]

On 10/11/2012 01:49 PM, Sean Kelly wrote:
> On Oct 10, 2012, at 6:55 PM, Charles Hixson<charleshixsn at earthlink.net>  wrote:
>>
>> TDPL quotes the recommendation from an Erlang book "Have LOTS of threads!", but doesn't really say how to guess at an order of magnitude of what's reasonable for D std.concurrency.  People on Erlang say that 100's of thousands of threads is reasonable.  Is it the same for D?
>
> Not currently.  spawn() generates a kernel thread, unlike a user-space thread as in Erlang, so you really can't go too crazy with spawning before the cost of context switches starts to hurt.  There was a thread about this recently in digitalmars.D, I believe.  To summarize, the issue blocking a move to user-space threads is the technical problem of making thread-local statics instead be local to a user-space thread.  That said, if you don't care about that detail it would be pretty easy to make std.concurrency use Fibers instead of Threads.

I'm not clear on what Fibers are.  From Ruby they seem to mean 
co-routines, and that doesn't have much advantage.  But it also seems as 
if other languages have other meanings.  TDPL doesn't list fiber in the 
index. I just found them in core.thread... but I'm still quite confused 
about what their advantages are, and how to properly use them.

OTOH, it looks as if Fibers are heavier than classes, and I was already 
planning on using structs rather than classes mainly because classes are 
heavier.  And if processes are even heavier... well, I need to use a 
different design.  Perhaps I can divvy the structs up four ways as in 
std.concurrency.  Perhaps I should use a parallel foreach, as in 
std.parallelism.  (That one looks really plausible. but I'm not sure 
what the overhead is when I'm doing more than a simple multiplication. 
Still, the example *looks* quite promising for this application.)  One 
of the advantages of std.parallelism::foreach is that I can code the 
application in serial as normal, and then add the parallelism later.  I 
wasn't intending to have deterministic interaction between the pieces 
anyway.  (But I am intending that some of the cells will send messages 
to other cells.  Something on the order of cells[i].bumpActivity; being 
issued by a cell other than cell i.)