2014-05-14 5 views
5

Mit einem Skript wiekorrekt gelaicht terminate runghc Prozess

-- foo.hs 
import System.Process 
import Control.Concurrent 

main = do 
    a <- runCommand "yes" 
    threadDelay 1000000 
    terminateProcess a 

ich erwartete Verhalten bekommen - yes läuft, bis die threadDelay oben ist. Aber wenn ich ersetzen "yes" mit "runghc bar.hs", wo bar.hs ist

import Control.Monad 
import Control.Concurrent 

main = forever (print 5 >> threadDelay 100000) 

... dann bar.hs läuft für immer. Gibt es eine bessere Möglichkeit, runghc zu beenden?

Edit: Dieses Verhalten auf Linux ist

Antwort

5

Das ziemlich lustig Verhalten ist. Was ist los ist, dass runghc seinen eigenen Kindprozess hervorbringt, und Sie töten den runghc Prozess, aber nicht das Kind. Die Verwendung von interruptProcessGroupOf anstelle von terminateProcess scheint hier den Trick zu machen, obwohl ich nicht wirklich genug weiß, um zu sagen, ob das eine zuverlässige/korrekte Lösung ist.

+0

Dieses Verhalten ist ziemlich überraschend, IMHO. Es könnte als ein Fehler der GHC-Laufzeit betrachtet werden, insbesondere weil das Kind nicht explizit vom Haskell-Programmierer erzeugt wurde, sondern von der Laufzeit, daher scheint es schwer zu überschreiben. – chi

+1

@chi Nun, ich bin mir sicher, dass es nicht die Laufzeit ist, sondern 'runghc', die sich dafür entscheidet, einen Prozess zu erzeugen. Aber ich stimme Ihrer Schlussfolgerung zu, dass es etwas überraschend ist, dass 'ranghc' sich dafür entscheidet. Ich vermute, dass dies nur der einfache Weg ist, es zu implementieren: Ich wette, wir sehen 'ghci'-Sandboxing im Wesentlichen, obwohl es keinen umschließenden Prozess gibt, der eine Sandbox benötigt. –

+0

Ich habe gemischten Erfolg mit '' 'interruptProcessGroupOf''', aber es ist besser als alles, was ich weiß. Vielen Dank – amindfv

Verwandte Themen