It seems that hPutBuffNonBlocking flush the buffer and blocks anyway when it has not enough space for the next message. -- else, we have to flush else do debugIO <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Internals.html#debugIO> "hPutBuf: flushing first" old_buf' <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606595> <- Buffered.flushWriteBuffer <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer> haDevice <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606575> old_buf <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text.html#local-1627606591> -- TODO: we should do a non-blocking flush here https://tldrify.com/bga this should be a bug or a feature not implemented. since the flush uses flushWriteBuffer <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer>, that blocks, hPutBuffNonBlocking does the same than hPutBuff and the buffer congestion can not be detected. I will try to do a new version with flushWriteBuffer0 <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO.html#flushWriteBuffer0> which do not blocks. 2015-09-17 15:41 GMT+02:00 james <james@mansionfamily.plus.com>:
On 17/09/2015 13:52, Brandon Allbery wrote:
... It is possible that recent network package changed this, but in the past *all* socket operations had to be under the aegis of *one* withSocketsDo, otherwise any handles, buffers, etc. would become invalid when Winsock was deinitialized.
See http://neilmitchell.blogspot.co.uk/2015/02/making-withsocketsdo-unnecessary....
-- Alberto.