
I just got myself a copy of ghc-6.2.1 and was idly experimenting with Network in ghci. I tried Prelude System.Posix Network> do r <- recvFrom "localhost"$ PortNumber 9090; putStr r in one ghci and Prelude Network> do sendTo "localhost" (PortNumber 9090) "jellied eels\n" in another and was pleased to see jellied eels pop out of the first. Unfortunately a second attempt is not so happy: Prelude System.Posix Network> do r <- recvFrom "localhost"$ PortNumber 9090; putStr r *** Exception: bind: resource busy (Address already in use) According to the documentation there's some mention of "Address already in use" on this mailing list, but I couldn't find it -- I thought there used to be searchable archives of the mailing lists, but I couldn't find those either and resorted to google. A little experimentation revealed that: do sock <- listenOn$PortNumber 7607; (hdl,host,port)<- accept sock; s<-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose sock is nicely repeatable. The following questions arise: * Shouldn't recvFrom call sClose itself? * If not, how should one clean up after using recvFrom? * Shouldn't sClose be reexported from Network? * is there a general way to get ghci out of a state where it's got stuff open on inaccessible sockets? Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

Jon Fairbairn wrote:
I just got myself a copy of ghc-6.2.1 and was idly experimenting with Network in ghci.
Unfortunately a second attempt is not so happy:
Prelude System.Posix Network> do r <- recvFrom "localhost"$ PortNumber 9090; putStr r *** Exception: bind: resource busy (Address already in use)
According to the documentation there's some mention of "Address already in use" on this mailing list, but I couldn't find it -- I thought there used to be searchable archives of the mailing lists, but I couldn't find those either and resorted to google.
A little experimentation revealed that:
do sock <- listenOn$PortNumber 7607; (hdl,host,port)<- accept sock; s<-IO.hGetContents hdl; putStr$s; IO.hClose hdl; Network.Socket.sClose sock
is nicely repeatable. The following questions arise:
* Shouldn't recvFrom call sClose itself?
recvFrom can't close the socket until the data has been consumed.
* If not, how should one clean up after using recvFrom?
You can't; once recvFrom returns, there's no way to get at the listening socket (or, for that matter, the connection socket).
* 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.
--
Glynn Clements
participants (2)
-
Glynn Clements
-
Jon Fairbairn