From ef56347debb950afc9452391f98c099d0b17ef56 Mon Sep 17 00:00:00 2001 From: Gabor Greif Date: Wed, 22 Jan 2020 18:24:14 -0500 Subject: Document the fact, that openFileBlocking can consume an OS thread indefinitely. Also state that a deadlock can happen with the non-threaded runtime. [ci skip] --- libraries/base/GHC/IO/Handle/FD.hs | 5 +++++ 1 file changed, 5 insertions(+) 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 -- cgit v1.2.1