Network, sClose

[Glynn Clements]

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 at virgin.net>