Hello, I have isolated a problem when using (lazy) ByteStrings through the network (GHC 6.12.1, Ubuntu 9.10 32bits): Here is my client: http://old.nabble.com/file/p28162932/Client.hs Client.hs And my server: http://old.nabble.com/file/p28162932/Server.hs Server.hs The server holds until the client closes the connection, even if I flush the handle on the client side after writing or even if I turn off buffering on both sides. ----- Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28162932.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
Apparently, the trouble seems to come from binary deserialization. When I read my handle with: inp <- L.hGet hdl 24 and no longer with: inp <- L.hGetContents hdl I get a lazy bytestring which is no longer infinite, and then deserialization occurs right. It proves that at the time of deserialization, the server has all the data it needs, and should not hold. I usually don't know the size of the structures I receive through network. I only know their type, and this should be sufficient for Data.Binary.decode, since it knows how to work with lazy bytestrings. Apparently, this example shows no problem with GHC 6.10. I think that network+binary is quite a common combination in Haskell, so is there anyone here who also uses GHC 6.12 and has this problem? Yves Parès wrote:
Hello,
I have isolated a problem when using (lazy) ByteStrings through the network (GHC 6.12.1, Ubuntu 9.10 32bits):
Here is my client: http://old.nabble.com/file/p28162932/Client.hs Client.hs And my server: http://old.nabble.com/file/p28162932/Server.hs Server.hs
The server holds until the client closes the connection, even if I flush the handle on the client side after writing or even if I turn off buffering on both sides.
----- Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28166613.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
News! (Sorry for the spam, but this problem turns to be a headache) The problem actually comes from ByteStrings (either lazy or strict). I reduced my server code to this: import Network import System.IO import qualified Data.ByteString(.Lazy) as L main = do (hdl,_,_) <- listenOn (PortNumber 7777) >>= accept hSetBuffering hdl NoBuffering inp <- L.hGetContents hdl putStrLn . show $ L.take 8 inp My client hasn't changed, and sends properly the data. So the server shouldn't hold. Well, even when trying to rawly print the first 8 bytes of the stream, it does. But when I use normal Strings, it doesn't hold: import Network import System.IO main = do (hdl,_,_) <- listenOn (PortNumber 7777) >>= accept hSetBuffering hdl NoBuffering inp <- hGetContents hdl putStrLn . show $ take 8 inp I think this behavior is normal for strict ByteStrings, but not for lazy ones... ----- Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Network%3A-buffering-troubles-tp28162932p28166941.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
participants (1)
-
Yves Parès