On Thu, 2012-10-11 at 09:09 +0200, thedeemon wrote: > On Thursday, 11 October 2012 at 02:21:01 UTC, Charles Hixson > wrote: > > I haven't been able to get an idea of how many std.concurrency > > receivers is reasonable. > > Currently in std.concurrency each "receiver" lives in its own OS > thread, so they are very expensive, 4-10 is fine, 100 may be > possible but expensive in terms of RAM and CPU cycles, 1000 is > probably too much.
In the beginning processors weren't doing enough so processes were invented. Processes were too expensive so threads were invented. Now threads are too expensive. How the world goes round :-) More constructively: there is an implication here that each receiver is bound explicitly and permanently to a thread. I would have thought the step would be de-couple receiver and thread, run a thread pool and then dynamically bind to receivers as needed. I haven't read the earlier emails in the thread nor checked the code so I may be way off with the above. Apologies if so. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
