- ghc-tickets - Haskell.org

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:11 simonmar]: > We would have to move the existing `ExitCode` datatype into the `haskell2010` package, and do the corresponding refactorings. ...what's exactly involved here? Does this mean, that `haskell2010` (as well as `haskell98`) gets a //distinct// `System.Exit.ExitCode` type (but with the same name) as the one remaining in `base`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:19 andersk]: > Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. that change would involve modifications to `haskell2010`, `base`, `process` and maybe `unix` if I understand it right... :-/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): Adding constructors to `ExitCode` seems to still be an option (comment:10, comment:11). I think that would make all the other proposed changes unnecessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Ok, in summary I see the following possibilities for the return value of the existing `waitForProcess` call on POSIX systems: 1. Use the reserved `ExitFailure 0` value to denote `WIFEXITED(s) == FALSE`; code should use the new API functions from comment:9 if it's interested in getting better exit-status information 2. Use the Perl/Python encoding convention for the argument of `ExitFailure`, i.e. {{{#!hs if coredump then 0x8000 else 0 .|. exit-status `shift` 8 .|. signum }}} causes impedance mismatch with the Haskell2010's `exitWith` 3. Use Bash-encoding for the argument of `ExitFailure` causes impedance mismatch with Haskell2010's `exitWith` I'm somewhat inclined to go with 1.; 2. would be tolerable if `exitWith` in base is adapted to interpret the exit code in the same way -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): Wikipedia is confused. If you go actually read the [http://pubs.opengroup.org/onlinepubs/9699919799/functions/wait.html specification], you see > WEXITSTATUS(stat_val): … this macro evaluates to the low-order 8 bits of the status argument that the child process passed to _exit() or exit(), or the value the child process returned from main(). and also > The status values are retrieved by macros, rather than given as specific bit encodings as they are in most historical implementations (and thus expected by existing programs). This was necessary to eliminate a limitation on the number of signals an implementation can support that was inherent in the traditional encodings. Here’s the [https://sourceware.org/git/?p=glibc.git;a=blob;f=bits/waitstatus.h;hb=refs/… definition] from glibc: {{{ /* If WIFEXITED(STATUS), the low-order 8 bits of the status. */ #define __WEXITSTATUS(status) (((status) & 0xff00) >> 8) /* If WIFSIGNALED(STATUS), the terminating signal. */ #define __WTERMSIG(status) ((status) & 0x7f) }}} which is to say that bits 8-15 of the wait()/waitpid() status are bits 0-7 of the exit() status (the rest of the exit() status being thrown away), and bits 0-6 of the wait()/waitpid() status are the signal number. This agrees with the Perl/Python encoding (because, of course, that’s where the Perl/Python encoding came from). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:7 andersk]: > that’s going to confuse anyone who knows that the real encoding is `(exit code << 8) + signal` (which, say, Perl forces you to learn). btw, what do you mean by //real// encoding? I've looked a bit around and here's what I've found so far: Python's [http://docs.python.org/3/library/os#os.wait os.wait()] operation which seem to match Perl's encoding: //... exit status indication: a 16-bit number, whose low byte is the signal number that killed the process, and whose high byte is the exit status (if the signal number is zero); the high bit of the low byte is set if a core file was produced.// ...otoh, Wikipedia says regarding [http://en.wikipedia.org/wiki/Exit_status#POSIX POSIX Exit status]: //... SUS specifies that the low-order 8 bits of the status value contain the exit status ...// -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 09 Nov '13

09 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): Replying to [comment:6 simonmar]: > Unfortunately we can't add the right information to `ExitCode`, because it is a platform-independent type. The correct type already exists: it is called `System.Posix.ProcessStatus`. > > {{{#!hs > data ProcessStatus = Exited ExitCode > | Terminated Signal > | Stopped Signal > deriving (Eq, Ord, Show) > }}} > > Unfortunately whoever wrote this forgot to add a `Bool` to indicate a core dump in the `Terminated` constructor. We *could* fix that. for the record, this has been implemented in [dc29d55b30d95f0838499fb48217e1d22e39d07d/unix] (which is included in the recently released [hackage:unix-2.7.0.0]) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 08 Nov '13

08 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by andersk): It looks like the current HEAD still uses the ambiguous (128 + signal) return codes from comment:3. I don’t pretend to speak for the developers, but from the following comments it looks like everyone agrees that committing to this API would be a mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient
by GHC 08 Nov '13

08 Nov '13

#3606: The Ord instance for unboxed arrays is very inefficient --------------------------------------------+------------------------------ Reporter: blarsen | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by hvr): * keywords: array, performance, Ord => array * os: Linux => Unknown/Multiple * milestone: 7.6.2 => 7.10.1 Old description: > The Ord instance for unboxed arrays defined in Data.Array.Base results in > code that makes lots of heap allocations and is very slow. > > For the record, the Ord instance is defined as so in Data.Array.Base: > > {{{ > instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where > compare = cmpUArray > > {-# INLINE cmpUArray #-} > cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e > -> Ordering > cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) > }}} > > The 'assocs' calls don't appear to be deforested away, and hence, when > using the Ord functions on unboxed arrays, the performance is bad to the > point of making them unusable. > > It seems reasonable to me that 'compare' for unboxed arrays could be > implemented strictly, in a tight loop, without any heap allocations at > all. New description: The Ord instance for unboxed arrays defined in `Data.Array.Base` results in code that makes lots of heap allocations and is very slow. For the record, the `Ord` instance is defined as so in `Data.Array.Base`: {{{#!hs instance (Ix ix, Ord e, IArray UArray e) => Ord (UArray ix e) where compare = cmpUArray {-# INLINE cmpUArray #-} cmpUArray :: (IArray UArray e, Ix i, Ord e) => UArray i e -> UArray i e -> Ordering cmpUArray arr1 arr2 = compare (assocs arr1) (assocs arr2) }}} The `assocs` calls don't appear to be deforested away, and hence, when using the `Ord` functions on unboxed arrays, the performance is bad to the point of making them unusable. It seems reasonable to me that `compare` for unboxed arrays could be implemented strictly, in a tight loop, without any heap allocations at all. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3606#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 08 Nov '13

08 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by hvr): ...is the current HEAD of [source:process] in a releasable state with respect to this ticket? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0