[GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix

GHC ghc-devs at haskell.org
Wed Mar 29 17:58:14 UTC 2017


#8684: hWaitForInput cannot be interrupted by async exceptions on unix
-------------------------------------+-------------------------------------
        Reporter:  nh2               |                Owner:  snoyberg
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:  7.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D42
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by nh2:

Old description:

> http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html
>
> claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact
> that's false (e.g. mentioned in
> https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4).
>
> {{{
> -- import Control.Concurrent
> import System.IO
> import System.Timeout
>
> main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000)
> }}}
>
> will not be killed after 1 second, but instead wait for the full 5
> seconds timeout passed to {{{hWaitForInput}}}.
>
> The implementation is {{{ready}}} at
> http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO-
> FD.html, where we have two foreign calls: {{{safe fdReady}}} and
> {{{unsafe unsafe_fdReady}}}.
>
> The actual C implementation is at https://github.com/haskell-
> suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on
> Unix, and does check for {{{EINTR}}}, so I believe that according to
> http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi-
> interruptible both foreign calls can be replaced by a single
> {{{interruptible}}} one.
>
> Is that true?
>
> If not, it's a documentation bug in {{{timeout}}} at least.
>
> Also, does {{{interruptible}}}, apart from allowing the function to be
> interrupted, behave more like {{{safe}}} or {{{unsafe}}}?

New description:

 http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html

 claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact
 that's false (e.g. mentioned in
 https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4).

 {{{
 -- import Control.Concurrent
 import System.IO
 import System.Timeout

 main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000)
 }}}

 will not be killed after 1 second, but instead wait for the full 5 seconds
 timeout passed to {{{hWaitForInput}}}.

 The implementation is {{{ready}}} at
 https://downloads.haskell.org/~ghc/7.6.3/docs/html/libraries/base/src/GHC-
 IO-FD.html, where we have two foreign calls: {{{safe fdReady}}} and
 {{{unsafe unsafe_fdReady}}}.

 The actual C implementation is at https://github.com/ghc/packages-
 base/blob/52c0b09036c36f1ed928663abb2f295fd36a88bb/cbits/inputReady.c#L16.
 It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe
 that according to
 http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi-
 interruptible both foreign calls can be replaced by a single
 {{{interruptible}}} one.

 Is that true?

 If not, it's a documentation bug in {{{timeout}}} at least.

 Also, does {{{interruptible}}}, apart from allowing the function to be
 interrupted, behave more like {{{safe}}} or {{{unsafe}}}?

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8684#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list