Broken SocketConduit.read() in non-blocking mode.

SocketConduit?.reader() doesn't currently do anything smart with the return value from the Socket. Anything <= than zero is considered Eof. Recently made passing an empty buffer be an exceptional condition, as a path toward solving this issue. We'll have to wait a bit to see how things pan out.

It seems that the problem is that it needs to return 2 types of values: The first indicates that there is no data to be read currently the non-blocking (EAGAIN or EWOULDBLOCK) case. This returns -1 from recv or write.

The second indicates that the connection has gone bad. the (*defined below) case. This returns 0 on a recv or write. This should return a different indicator than eof. It is a very common occurrence in asynchronous or multithreaded programs which queue up events or waiting sockets, or apps which use EPoll and may never actually receive a hangup event.

In the case of a recv on a bad socket, the call will return 0. I could imagine that SocketConduit? doesn't want to return 0 on error, since it's probably a very valid case for other conduits.

I propose that for read and write. If a -1 is returned, we return Eof. If a 0 is returned, we return BadFd? (or some descriptive term indicating that the connection is no longer valid) It should be able to be safely defined as -2 or somesuch.

NOTE: There is a better workaround for this than using Socket.Receive. You can use tango.stdc.errno.getErrno() upon receiving a Eof from a SocketConduit?. For the hangup or bad file socket: ECONNABORTED ECONNRESET EINVAL ENETDOWN ENETRESET ENOTCONN ESHUTDOWN ETIMEDOUT

For the nonBlocking not ready event case, one would receive: EAGAIN EWOULDBLOCK (I think that those are defined to be the same thing on most systems)

Also note: errno is broken on a multithreaded system because it is an external global variable, your function may have just returned an error, but some other function in another thread could have errored and set errno to something else before your thread checks the value)

Note that this is a workaround. I don't think that the customer of SocketConduit?, a high level library, should have to be making low-level calls to check the errno value.

thanks rrichardson ... have not forgotten about this :)

• what's a good way to fix the errno issue?
• returning two error values doesn't jive with the rest of the package, I'm afraid. Not sure how to fix that :'(