Network I/O and streaming in D2

[Sean Kelly]

Andrei Alexandrescu Wrote:

> Sean Kelly wrote:
> > Walter Bright Wrote:
> > 
> >> Sean Kelly wrote:
> >>> Walter Bright Wrote:
> >>>
> >>>> Adam Ruppe wrote:
> >>>>> My network thing is very simple: it opens a socket, then wraps it up
> >>>>> in a File struct, via FILE*. Then, you can treat it the same way.
> >>>> That's the traditional way to do it, but I'm not so sure it's the right way for 
> >>>> the future. Wouldn't it be better to have an interface to it that is a range, 
> >>>> rather than pretend it's a FILE* ?
> >>> And in either case, if the buffer is empty a get() operation will block, correct?
> >> I'm no expert in network programming, but yes. I suspect there should be a 
> >> settable timeout which should throw, too.
> > 
> > I've been thinking about this and I think this is probably what the majority of apps want anyway.  It isn't scalable, but server apps are a whole 'nother ball of wax.
> 
> To obtain asynchronous operation, an app can spawn a secondary thread 
> using blocking I/O and passing stuff as messages. Indeed defining many 
> secondary threads does become a scalability issue.

Yeah, this is where Java was 10 years ago.  It's an easy model to program for but scales terribly, assuming you're talking about kernel threads.  If the threads are replaced with fibers and context-switching takes place behind the scenes when a read or write is issued it's actually a pretty cool programming model that should scale quite well.  So I suppose it's not a bad model to expose to users, since we'll eventually be 64-bit and fibers will probably be used by spawn() at some point.