-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility with GNU Parallel #1084
Comments
For the second problem, Parallel tries to execute a POSIX script in the current function parallel;
set -lx SHELL bash
command parallel $argv
end The first problem is proving harder to replicate. It occurs less than 1% of the time (try |
If we ever do threaded execution #563 we could provide a totally kick-ass builtin parallel. |
If you start a huge stack of fish processes, fishd eventually dies with SIGPIPE. Does the fish side of things get done on a background thread or something? I wonder if fish is starting, finishing its work before getting a reply from fishd and tearing everything down. Would it be safe to set SIGPIPE as ignored in the startup of fishd? It will still get EPIPE but that can be safely ignored. |
This appears to fix the problem: diff --git a/fishd.cpp b/fishd.cpp
index 5e2a364..30ded3c 100644
--- a/fishd.cpp
+++ b/fishd.cpp
@@ -667,13 +667,14 @@ static void daemonize()
setup_fork_guards();
/*
- Make fishd ignore the HUP signal.
+ Make fishd ignore the HUP and PIPE signals.
*/
struct sigaction act;
sigemptyset(& act.sa_mask);
act.sa_flags=0;
act.sa_handler=SIG_IGN;
sigaction(SIGHUP, &act, 0);
+ sigaction(SIGPIPE, &act, 0);
/*
Make fishd save and exit on the TERM signal. Not sure if it's ok though. |
I think this fix is the right thing to do. But before we apply it I want to understand why we're getting SIGPIPE. My understanding is that all communication with fishd happens on the main thread and is synchronous, and furthermore that all data sent by fishd is in response to a request from a fish instance (so fishd never initiates). Based on that I'd expect to never get SIGPIPE unless a fish instance crashes, and if we're crashing I very much want to know :) zanchey, can you share your technique for starting a huge stack of fish instances? |
I'm not sure this zanchey's technique (sorry if it's not), but the following makes things go really wrong :
This produces A LOT of error messages and sometimes even backtraces. |
Ooh, nice find. Thanks! |
As above - I use The failure is disappointingly intermittent; on my local machine, I am yet to be able to reproduce it, but it is much more frequent on some remote machines. |
Now I get it - it's very simple. If fishd begins a write before fish starts reading it, and fish exits, then fishd will get SIGPIPE. Ignoring SIGPIPE is the right thing to do. |
Should be fixed by de8bae3 . Thanks for reporting this. |
I tried parallelizing some programs with GNU Parallel (http://www.gnu.org/software/parallel/), but fish produces some warnings/errors. For instance:
Or:
I'm running OSX 10.9 with fish installed by Homebrew and set as my default shell.
The text was updated successfully, but these errors were encountered: