Some of the answer to your questions depends on how the signal handler gets set up. I think we're looking at this in the context of setting signal handlers via the
sigaction(2) system call.
One of the elements of a
struct sigaction is named "sa_mask". From
man 2 sigaction:
sa_mask gives a mask of signals which should be blocked during execution of the
signal handler. In addition, the signal which triggered the handler will be
blocked, unless the SA_NODEFER flag is used.
It looks like if you set up correctly, even the signal being handled isn't blocked. Personally, I can't imagine a use for that, but I have a notoriously limited imagination.
So, I would say "yes, there's a window between signal generation and invocation of the receiving processes signal handler". So, other signals could get generated and sent to the receiving process. As far as what happens to those "other signals": it looks like signals aren't "queued": see this stackoverflow answer, except for "real time" signals. That is, if the kernel gets a bunch of
kill(some_pid, SIGHUP), the process denoted by
some_pid will have it's SIGHUP signal handler function invoked once.