Bayley, Alistair wrote:
* Shouldn't sClose be reexported from Network?
Once you start down that route, you end up at the inevitable conclusion that everything from the raw syscall imports upwards needs to be re-exported.
* is there a general way to get ghci out of a state where it's got stuff open on inaccessible sockets?
The solution to most problems with the Network module is not to use the Network module, but to use Network.Socket instead.
I had a similar (same?) problem while playing with networking, which was that you could open a socket and do stuff to it with just the functions from Network, but to properly close it you had to use Network.Socket.sClose. It also struck me as odd that Network exported all I needed to use sockets *except* sClose.
However, even if sClose was exported, that wouldn't be of any help in Jon's case, as neither of the sockets which recvFrom creates are visible outside of recvFrom. Essentially, Network.recvFrom is only of use to "simple, stupid programs"; specifically, programs which only wish to accept a single connection. Also, the use of lazy I/O means that the connection may be closed prematurely (resulting in EPIPE/SIGPIPE at the client end) if the program fails to "consume" all of the data (e.g. due to lazy evaluation). Additionally, it will throw an exception if it can't get the client's hostname (which is quite possible; many IP blocks don't have PTR records, particularly the private blocks, e.g. 192.168.*). -- Glynn Clements <glynn.clements@virgin.net>