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.
But - as I mentioned in another post - it looks like "interrupted system call" problem happens only with select and not eg. with blocking read. This means that current behaviour is inconsistent between std.socket functions. Also it was possible to make this work for read (I believe this bug & fix address that - http://d.puremagic.com/issues/show_bug.cgi?id=2242) and I don't think anyone considered it as "compatibility breaking", so why not take the same route for select? -- Marek Janukowicz
