[phobos] Fwd: [Issue 4025] New: Making network with the std.stdio.File interface

[Andrei Alexandrescu]

On 03/29/2010 05:40 AM, Steve Schveighoffer wrote:
> As far as the network library, do we want to increase our dependency
> on the C FILE* structure/api?  I would not want that.  I don't know a
> lot of network solutions that put a socket fd inside a FILE *,
> there's probably good reason for that.

That's a good question. I agree that we shouldn't make things dependent 
on the old FILE* API, but on the other hand File doesn't have a lot to 
do with it. I think it still offers a way to tease the handle out, but 
under an unsavory name.

> As long as there's a non-buffered solution that allows socket-like
> functions accessible, I'm cool with File wrapping a socket.  That is,
> there should be a way to create a socket with the API that doesn't
> use File.
>
> I hope we will eventually get a D-only solution for File.  Good news
> is, any future improvements to File automatically translate to what
> Adam is working on.

Exactly. There are some good ranges already and we plan more.

The problem with File and FILE* is the connection with stdio. Truth is, 
people will want to use stdin and stdout in D programs. Also, people 
will want to call C functions without being afraid that I/O will be garbled.

C++ has the sync_with_stdio solution, which is beyond horrible:

http://www.cplusplus.com/reference/iostream/ios_base/sync_with_stdio/

By default synchronization is on, which reduces the speed of iostreams 
by a large factor. The fact that they are slow to begin with doesn't 
help either.

We want something that's as far to that design as possible. Walter and I 
talked at length about this. After having investigated the problem, I 
concluded that we can efficiently implement File and its related ranges 
with FILE* and regular stdio by using nonstandard functionality. That 
functionality is in Gnu's stdio for Linux and dmc's stdio implementation 
for Windows. We'll also keep some less efficient generic implementation 
to ease porting to new systems. I don't know how to optimize for OSX.


Andrei