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.Inte...
"hPutBuf: flushing first" old_buf'
https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text...
<- Buffered.flushWriteBuffer
https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.BufferedIO....
haDevice https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text...
old_buf https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.IO.Handle.Text...
-- 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....,
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....
which
do not blocks.
2015-09-17 15:41 GMT+02:00 james
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.