Document how to close sockets in a threaded scenario about network HOT 7 OPEN

Note: Experimentally, async exceptions seem to be delivered to blocked threads. This is on arch linux + nix with these package versions:

> cabal list --installed
Cabal 3.6.3.0
HUnit 1.6.2.0
OneTuple 0.3.1
QuickCheck 2.14.2
StateVar 1.2.2
adjunctions 4.4.2
ansi-terminal 0.11.4
ansi-wl-pprint 0.6.9
array 0.5.4.0
assoc 1.0.2
async 2.2.4
base 4.16.4.0
base-orphans 0.8.7
bifunctors 5.5.14
binary 0.8.9.0
bytestring 0.11.4.0
call-stack 0.4.0
clock 0.8.3
colour 2.3.6
comonad 5.0.8
containers 0.6.5.1
contravariant 1.5.5
data-array-byte 0.1.0.1
deepseq 1.4.6.1
directory 1.3.6.2
distributive 0.6.2.1
exceptions 0.10.4
extra 1.7.12
filepath 1.4.2.2
free 5.1.10
ghc 9.2.7
ghc-bignum 1.2
ghc-boot 9.2.7
ghc-boot-th 9.2.7
ghc-compact 0.1.0.0
ghc-heap 9.2.7
ghc-prim 0.8.0
ghci 9.2.7
hashable 1.4.2.0
haskeline 0.8.2
hpc 0.6.1.0
hspec 2.9.7
hspec-core 2.9.7
hspec-discover 2.9.7
hspec-expectations 0.8.2
indexed-traversable 0.1.2
indexed-traversable-instances 0.1.1.1
integer-gmp 1.1
invariant 0.6
kan-extensions 5.2.5
lens 5.1.1
libiserv 9.2.7
mtl 2.2.2
network 3.1.2.7
optparse-applicative 0.17.0.0
package-version 0.3
parallel 3.2.2.0
parsec 3.1.15.0
pretty 1.1.3.6
prettyprinter 1.7.1
primitive 0.7.3.0
process 1.6.16.0
profunctors 5.6.2
quickcheck-io 0.2.0
random 1.2.1.1
record-dot-preprocessor 0.2.15
record-hasfield 1.0
reflection 2.1.6
relude 1.1.0.0
rts 1.0.2
safe-exceptions 0.1.7.3
semigroupoids 5.3.7
semigroups 0.20
setenv 0.1.1.3
splitmix 0.1.0.4
stm 2.5.0.2
strict 0.4.0.1
syb 0.7.2.2
tagged 0.8.6.1
template-haskell 2.18.0.0
terminfo 0.4.1.5
text 1.2.5.0
tf-random 0.5
th-abstraction 0.4.5.0
these 1.1.1.1
time 1.11.1.1
transformers 0.5.6.2
transformers-base 0.4.6
transformers-compat 0.7.2
uniplate 1.6.13
unix 2.7.2.2
unordered-containers 0.2.19.1
validation 1.1.2
vector 0.12.3.1
void 0.7.3
xhtml 3000.2.2.1

from network.

We implemented a way to use duplex connections in IOG, although in a more complex scenario. We have a component which tracks state of the connection, e.g. in which direction it is being used. We do it at the protocol level (communication protocol which we implemented), while for taking care of socket we simply use bracket (socket ...) close ... (well almost...).

What I would do is implement a simple protocol which has a termination message, then in the bracket callback you could wait receiving termination message & terminating the local sender before exiting the callback (which will let bracket close the socket).

from network.

Usually, shutdown should be used.

@voidus You are using UNIX-domain sockets. I don't understand why socket-specific is not a good solution.

from network.

@coot I'd rather not depend on the connecting applications being well-behaved on both ends.

@kazu-yamamoto I'm not sure what you mean with socket-specific. I tried to search for it but couldn't find anything really.
If I understand you correctly, calling shutdown on a socket guarantees that the thread will wake up. Is that correct?

from network.

@voidus

You said "but that seems like a worse solution because it is socket-specific" in the first comment. I would like to know why you think so.

from network.

If I understand you correctly, calling shutdown on a socket guarantees that the thread will wake up. Is that correct?

When thread A calls shutdown sock ShutdownSend, recv of thread B returns with "".

from network.

Honestly, looking back, I'd say it's because I'm writing a lot of python and have no hesitation to use exceptions for control flow. The other reason why I thought it would be better is that it's applicable in other situations as well, so it felt like a more general solution.

I'll prepare a PR for brief documentation changes that would have helped me.

from network.