• Sean Kelly <sean invisibleduck.org> Oct 12 2010

Sean Kelly <sean invisibleduck.org> writes:

Denis Koroskin Wrote:

 On Tue, 12 Oct 2010 02:32:55 +0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 
 For me, I/O should be scalable (and thus support async operations) so I  
 came up with my own implementation.
 I've tried building it on top of std.concurrency, but it doesn't scale  
 either. So, once again, I had to implement my own message passing  
 mechanism. I can implement existing std.concurrency interface on top of my  
 own one without sacrificing anything, but not vice-versa).


 Unlike std.concurrency, it is easy (and encouraged) to have as many  
 mailboxes as you need. Mailboxes can forward events to other mailboxes,  
 e.g. so that you can poll() only one mailbox (and not every single one of  
 them).


Pretty cool.  I'm not sure I would consider poll() scalable though.  Or at
least not to the levels where my concept of "scalable" applies.  That aside, I
think the correct approach is to have an IO API that stands by itself and then
provide a few adaptors for integrating it with messaging in different ways. 
That will allow performance-minded folks to do their to-the-metal programming
and convenience-minded folks to unify IO with the rest of their
message-passing.  This is one thing that I feel Erlang got wrong.  The
IO-messaging integration is too magic, and ends up being problematic (try
handing control of a socket from one process to another, for example, without
losing any in-flight messages in the process).  In short, I think I agree with
you than std.concurrency isn't exactly right for this.  At least as the default
interface at any rate.