Network server design question

[David Nadlinger]

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