[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Parallel Bug Reports Exit status for semaphore mode
From: |
Ole Tange |
Subject: |
Re: GNU Parallel Bug Reports Exit status for semaphore mode |
Date: |
Fri, 18 Jan 2019 10:13:38 +0100 |
On Wed, Jan 16, 2019 at 4:35 PM Gregor Jasny <address@hidden> wrote:
>
> I'm wondering how top propagate errors in semaphore mode.
Good idea.
> I'd expect
> that any calls of "parallel" either when submitting jobs or when waiting
> for the result return a non-zero exit code.
That would not be unreasonable to expect.
> I can see that implementing or defining error handling is problematic
> especially because returning the error is deferred. But nevertheless
> error handling is important and it would be nice if parallel could be
> helpful in that area.
The submitter obviously cannot get the error code: It only starts the
command, and does not wait for any jobs to stop.
The --wait'er, however, might be able to return the correct value.
We would need some way for the --wait'er to get the information. What
if there are multiple --wait'ers?
What should happen in a -j1 situation?
What should happen in a -j100 situation? If one finishes? If multiple finishes?
What should happen in a -j1000 situation?
What should happen in a -j0 situation?
A key feature of GNU Parallel is to try hard to avoid having the user
to clean up afterwards. So leaving a lot of dead files is a no-go
(e.g. a file with the exitcode).
In your example I think you can rewrite it to use parallel instead of
sem, but I can see that it will not always to be easy to do that.
/Ole