Re: Why sourcing a file is not faster than doing a loop with eval, zle -N

[Bart Schaefer <schaefer@brasslantern.com>]

On Jun 19,  1:24pm, Stephane Chazelas wrote:
}
} There's probably scope for optimisation here, though I can't
} comment further as I don't know why that signal handling code is
} there in the first place.

rt_signprocmask should not be significantly more expensive than an
assignment to an integer.

The signal handling code is there because the shell MUST NOT respond
instantly to arbitrary signals while doing operations such as token
interpretation or or memory management -- the signal handlers might
themselves invoke shell commands/functions and many of those layers
are not safe for re-entrancy -- but it MUST respond to those signals 
whenever it may be blocked for an unknown length of time, such as when
reading from a file descriptor.

Many years of "I can't interrupt my script when X" or "interrupting
my script when Y causes a crash" resulted in the current signal
paradigm.  When the shell was first written, processors weren't fast
enough and process scheduling not well-threaded enough to expose a
lot of these issues, but the better our computers get the greater
the likelyhood of hitting an ever-smaller race condition window, so
those windows have to be aggressively closed.