summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGabor Greif <ggreif@gmail.com>2020-01-22 18:24:14 -0500
committerGabor Greif <ggreif@gmail.com>2020-01-22 18:24:14 -0500
commitef56347debb950afc9452391f98c099d0b17ef56 (patch)
treee3321d50e90a6471875e7f6cdd62f9da1ded0ef3
parent3dae006fc424e768bb43fc73851a08fefcb732a5 (diff)
downloadhaskell-wip/ggreif-openFileBlocking.tar.gz
Document the fact, that openFileBlocking can consume an OS thread indefinitely.wip/ggreif-openFileBlocking
Also state that a deadlock can happen with the non-threaded runtime. [ci skip]
-rw-r--r--libraries/base/GHC/IO/Handle/FD.hs5
1 files changed, 5 insertions, 0 deletions
diff --git a/libraries/base/GHC/IO/Handle/FD.hs b/libraries/base/GHC/IO/Handle/FD.hs
index 64179768c9..122331f17d 100644
--- a/libraries/base/GHC/IO/Handle/FD.hs
+++ b/libraries/base/GHC/IO/Handle/FD.hs
@@ -150,6 +150,11 @@ openFile fp im =
-- This can be useful for opening a FIFO for writing: if we open in
-- non-blocking mode then the open will fail if there are no readers,
-- whereas a blocking open will block until a reader appear.
+--
+-- Note: when blocking happens, an OS thread becomes tied up with the
+-- processing, so the program must have at least another OS thread if
+-- it wants to unblock itself. By corollary, a non-threaded runtime
+-- will need a process-external trigger in order to become unblocked.
--
-- @since 4.4.0.0
openFileBlocking :: FilePath -> IOMode -> IO Handle