Am Mon, 05 Aug 2013 16:07:40 +0200 schrieb "David Nadlinger" <[email protected]>:
> 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.
