Network server design question

[Johannes Pfau]

Am Mon, 05 Aug 2013 16:07:40 +0200
schrieb "David Nadlinger" <code at klickverbot.at>:

> On Monday, 5 August 2013 at 06:36:15 UTC, Johannes Pfau wrote:
> > This is a bug in std.socket BTW. Blocking calls will get 
> > interrupted by
> > the GC - there's no way to avoid that - but std.socket should 
> > handle
> > this internally and just retry the interrupted operation. 
> > Please file a
> > bug report about this.
> 
> I'm not sure whether we can do anything about Socket.select 
> itself at this point, as it would be a breaking API change – 
> interrupted calls returning a negative value is even mentioned 
> explicitly in the docs.
> 
> There should, however, be a way to implement this in a 
> platform-independent manner in client code, or even a second 
> version that handles signal interruptions internally.
> 
> > (Partial writes is another issue that could/should be handled in
> > std.socket so the user doesn't have to care about it)
> 
> I don't think that would be possible – std.socket by design is a 
> thin wrapper around BSD sockets (whether that's a good idea or 
> not is another question), and how to handle partial writes 
> depends entirely on the environment the socket is used in (think 
> event-based architecture using fibers vs. other designs).
> 
> In general, I wonder what the best way for going forward with 
> std.socket is. Sure, we could try to slowly morph it into a 
> "modern" networking implementation, but the current state also 
> has its merits, as it allows people to use the familiar BSD 
> sockets API without having to worry about all the trivial 
> differences between the platforms (e.g. in symbol names).
> 
> We should definitely add a note to std.socket though that it is a 
> low-level API and that there might be a better choice for most 
> applications (e.g. vibe.d, Thrift, …).
> 
> David

You're right, I somehow thought std.socket was supposed to offer a high
level API. But as it was designed as a low level wrapper we probably
can't do much without breaking API compatibility.