Why is GHCi so hard to kill?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why is GHCi so hard to kill?

Jeremy Henty

If I  put ghci into  a loop  by entering "last  $ repeat ()"  then the
process is impossible  to interrupt or kill except  with "kill -KILL".
(Although it can be stopped with Ctrl-Z.)  "kill -TERM" does not work.
The  same is  true if  I run  a runhaskell  script containing  "main =
putStrLn $ show $ last $ repeat $ ()".

Is  there a  reason for  ghci being  so unkillable?   It is  generally
considered a bad idea for a program to ignore the TERM signal.

(Details: Debian Linux Jessie 8.8, GHC 8.0.2 (built from source).)

Regards,

Jeremy Henty
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Why is GHCi so hard to kill?

Ruben Astudillo
On 18/05/17 03:09, Jeremy Henty wrote:
> Is  there a  reason for  ghci being  so unkillable?   It is  generally
> considered a bad idea for a program to ignore the TERM signal.

it has to do with passing the exception to the program running
inside ghci. Your example didn't manifest it because it was pure
functions

    ghci> (last $ repeat ()) :: ()

and those don't catch exceptions. Yet if you put

    ghci> import Control.Monad (forever)
    ghci> forever (putStrLn "howdy")

it will print forever until you press C-c on your terminal, as IO
actions can react to exceptions and have a default handler for C-c.

SIGKILL acted inmediatly because it isn't really a signal, the kernel
just kills the process.

--
-- Ruben


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why is GHCi so hard to kill?

Jonas Scholl
In reply to this post by Jeremy Henty
I think the reason is that no memory allocation occurs in the loop you
are trying to interrupt. Thus, the RTS can not stop the Haskell thread
to terminate the program after catching the signal.

You can only stop a Haskell thread if you are at a safe-point (i.e.
memory allocation). If you call a function like 'last', which is already
compiled, you get this behavior (you can kill it if you define last in
ghci itself, because then it is interpreted instead of using the
compiled version). There is a flag (-fno-omit-yields) to compile a
module with additional safe-points if there is no memory allocation
going on in a loop, but base is build without it, so you get the
behavior you observe.

On 05/18/2017 09:09 AM, Jeremy Henty wrote:

>
> If I  put ghci into  a loop  by entering "last  $ repeat ()"  then the
> process is impossible  to interrupt or kill except  with "kill -KILL".
> (Although it can be stopped with Ctrl-Z.)  "kill -TERM" does not work.
> The  same is  true if  I run  a runhaskell  script containing  "main =
> putStrLn $ show $ last $ repeat $ ()".
>
> Is  there a  reason for  ghci being  so unkillable?   It is  generally
> considered a bad idea for a program to ignore the TERM signal.
>
> (Details: Debian Linux Jessie 8.8, GHC 8.0.2 (built from source).)
>
> Regards,
>
> Jeremy Henty
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

signature.asc (499 bytes) Download Attachment