When is a signal handled and why does some info freeze up?

termA does not freeze up. It is just displaying the callback in the input box. Simply push the Enter key to continue with the input.

Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.

How signal handlers work?

A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)

#include <stdio.h>
#include <signal.h>

/* signal handler definition */
void signal_handler(int signum){
  printf("Hello World!\n");
}

int main(){
  //Handle SIGINT with a signal handler
  signal(SIGINT, signal_handler);
  //loop forever!
  while(1);
}

It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:

gcc -Wall -o sighdl.o signal.c
./sighdl.o 
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!

As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl-\ did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.

While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).

To answer your questions,

The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates

The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases

type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep

1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.

Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.

2.Open a new terminal ,named termB and run pkill -USR1 -f callback.sh first time,the info pop up instantly in termA

Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.

As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.

Go on in termB,run pkill -USR1 -f callback.sh the second time.

Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.

---

Image source: The Linux Programming Interface by Michael KerrisK

The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates.

bash does handle the signals at C / implementation level, but will not run the handlers set with trap until the foreground process has terminated. That's required by the standard:

When a signal for which a trap has been set is received while the shell is waiting for the completion of a utility executing a foreground command, the trap associated with that signal shall not be executed until after the foreground command has completed.

Notice that the standard makes no difference between builtins and external commands; in the case of a "utility" like read, which is not executed in a separate process, it's not obvious whether a signal occurs in its "context" or in that of the main shell, and whether a handler set with trap should be run before or after the read returns.

issue 1:callback.sh contains a infinite while loop,how to explain it does not handle any signals received until the foreground process terminates.,in this case the foreground process never terminates.

That's wrong. bash is not executing the while loop in a separate process. Since there's no foreground process bash is waiting on, it can run any handler set with trap immediately. If read were an external command, that and not while would be the foreground process.

issue2: No please input something for foo: shown in termA;

go to termB, run pkill -USR1 -f callback.sh the third time.

The following info shown in termA again: callback function called at Mon Nov 19 09:07:24 HKT 2018

Still no please input something for foo: shown in termA. Why the info please input something for foo: freeze up?

It doesn't freeze up. Just press Enter and it will show up again.

It's simply that

a) bash will restart the read builtin in place when interrupted by a signal -- it won't return and go again through the while loop

b) it will not re-display the prompt set with -p in that case.

Notice that bash won't even show the prompt again in the case where a SIGINT from the keyboard was handled, even if it does discard the string read so far from the user:

$ cat goo
trap 'echo INT' INT
echo $$
read -p 'enter something: ' var
echo "you entered '$var'"

$ bash goo
24035
enter something: foo<Ctrl-C>^CINT
<Ctrl-C>^CINT
<Ctrl-C>^CINT
bar<Enter>
you entered 'bar'

That will print you entered 'foobar' if the signal was sent from another window with kill -INT <pid> instead of with Ctrl-C from the terminal.

All the stuff in this last part (how read is interrupted, etc) is very bash specific. In other shells like ksh or dash, and even in bash when run in POSIX mode (bash --posix), any handled signal will actually interrupt the read builtin. In the example above, the shell will print you entered '' and exit after the first ^C, and if the read is called from a loop, the loop will be restarted.