summaryrefslogtreecommitdiff
path: root/Vagrantfile
diff options
context:
space:
mode:
authorMichael Snoyman <michael@snoyman.com>2016-10-01 21:24:05 -0400
committerBen Gamari <ben@smart-cactus.org>2016-10-02 14:57:44 -0400
commit42f1d86770f963cf810aa4d31757dda8a08a52fa (patch)
tree99400e6db8b967bda704df4ea1e431cc1e7a63f7 /Vagrantfile
parent4d2b15d5895ea10a64194bffe8c321e447e39683 (diff)
downloadhaskell-42f1d86770f963cf810aa4d31757dda8a08a52fa.tar.gz
runghc: use executeFile to run ghc process on POSIX
This means that, on POSIX systems, there will be only one ghc process used for running scripts, as opposed to the current situation of a runghc process and a ghc process. Beyond minor performance benefits of not having an extra fork and resident process, the more important impact of this is automatically getting proper signal handling. I noticed this problem myself when running runghc as PID1 inside a Docker container. I attempted to create a shim library for executeFile that would work for both POSIX and Windows, but unfortunately I ran into issues with exit codes being propagated correctly (see https://github.com/fpco/replace-process/issues/2). Therefore, this patch leaves the Windows behavior unchanged. Given that signals are a POSIX issue, this isn't too bad a trade-off. If someone has suggestions for better Windows _exec support, please let me know. Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2538
Diffstat (limited to 'Vagrantfile')
0 files changed, 0 insertions, 0 deletions