Network I/O and streaming in D2

[Steven Schveighoffer]

On Wed, 30 Jun 2010 13:13:33 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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* ?
>
> I initially also thought that a file (or socket etc.) should be a range,  
> but then I realized that that would overload roles. It's best to have a  
> handle/ranges architecture in which the handle (e.g. File) is  
> responsible for opening, closing, and managing the connection, and  
> several ranges are responsible for fetching data in various ways (by  
> character, by chunk, by line etc.)
>
> BTW I'm virtually done implemented readf. I only need to parse  
> floating-point numbers and strtod won't work. Walter, could you please  
> email me your strtod implementation? Thanks.
>
> The current issue with readf (and other similar formatted read routines)  
> is that they require a primitive peek() that looks up the current  
> character in a stream without swallowing it. This is not a FILE*  
> primitive, but can be simulated (slow) by using getc() and ungetc().  
> Fortunately on GNU's I/O libs peek() is easy to define (actually they  
> have an internal routine by that name), and on Windows dmd uses Walter's  
> I/O library, which again has fast peek().

I really think D needs to replace FILE * with it's own buffering scheme.   
That way we can control the underlying buffering and have access to it.   
We can also take advantage of D features that aren't available in the  
underlying code, such as thread local storage to avoid taking global locks.

-Steve