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
