[information/clarification] Does `block` affect `--on-process-exit`, `--on-job-exit`, `--on-variable` and/or `--on-signal` functions? about fish-shell

[faho]

The use case for which lucid prompt uses block is to ensure no "process exit" events are processed until the corresponding --on-process-exit handler is set up.

This hasn't been necessary since #7210 and 6d00ad1

[faho]

It blocks all events - --on-event is merely what we internally call a "generic" event, the others are also events.

block is, at the moment, essentially unusable and we're most likely going to remove it. See #9030.

[giorgiga]

Thanks @faho, please bear with me some more :)

The use case for which lucid prompt uses block is to ensure no "process exit" events are processed until the corresponding --on-process-exit handler is set up.

In code (this is of course made-up to illustrate the point in a terser way than by referencing the lucid code):

begin
    block -l
    sh -c 'echo "doing some work in the background..."' &
    sleep 1 # enough time to ensure the background job completes
    set -l pid $last_pid
    function __on_pid_{$pid}_exit --on-process-exit $pid
        echo "the background work has been done"
        functions -e (status function) # cleanup
    end
end

In my tests, the code above seems to run "well" regardless of whether the initial block -l line is included or commended out.

I assume that must (?) be because there is only one thread that runs the begin..end block and the __on_pid_x_exit function and, moreover, that thread determines which --on-process-exit to run by some kind of polling rather the handler functions being identified asynchronously when SIGCHLD is received.

Now, unless the above behavior is "set in stone" so that one can rely on it (but I can't find it documented anywhere?) and not just how the current C++ implementation turned out to behave, I believe removing block would leave no general solution for this use case.

Does this seem to make sense?

[giorgiga]

BTW:

hydro works around the problem by using universal variables as events (ie. the background job sets an universal variable when it's done, and the parent shell reacts via an --on-variable function it had previously registered), but that has two drawbacks:

1. it requires the background job to be a fish instance (and not one started with --no-config, which makes startup considerably slower)
2. it only works as long as one can guarantee there is only one such background job running at the same time

[giorgiga]

That's great then :)

I'll add a TODO to clarify the documentation in my personal TODO list (no promises though)