In the lecture video, it sounds like the signal that arrives in the middle of list_insert() is unpredictable (...) I am kind of confused about how the function (for example, the `list_insert()' in the video) receives the signal when that function is executing normally.

Signal delivery can occur at any instruction. Consider the common case of an SMP system where your shell runs on one core and its child process runs on another. When the child process exits, it performs the exit(2) system call (exit_group in Linux). It enters the kernel - the kernel performs a process exit, performs cleanup of resources, deallocates the process's data structures etc., and it'll notice that it needs to send SIGCHLD to the parent process. So it marks SIGCHLD as pending in the parent process's pending signal mask.

Now - signals should be delivered in a timely fashion and not be delayed unnecessarily. The process to which the signal is directed is running on a different core as assumed above. At this point, the kernel (as part of the child's exit code path) performs an Interprocessor Interrupt (IPI) towards the CPU on which the parent process runs. This is a true interrupt - it may hit the target processor at any instruction where interrupts aren't disabled - as is the case in user mode - including any instruction in the middle of a user program function like list_insert. When the interrupt occurs, the target processor enters the kernel. It checks the current process's pending signal mask and realizes the reason that it was sent this interrupt was to deliver a signal. Since it was interrupted in user mode, it will immediately deliver the signal (provided it's not blocked by the process) - set up a signal stack frame, etc., and branch to the signal handler in user mode to handle SIGCHLD.

That's why it appears that the signal arrives in the middle of a function, because it actually does. Once the signal handler returns, a special system call is made (sigreturn(2)) to tell the kernel that the signal handling is complete. At this point, the parent process will "return" from the IPI, and continue with the instruction at which the interrupt occurred (which is still in the middle of said function).

The lesson here is that control flow can be diverted at any instruction unless the process takes precaution to block signals during certain section of code where it doesn't wish to be interrupted by signal delivery. Note that all of this happens "under the hood" - mainly done by the kernel, but the programmer-observable behavior is that of a function call "out of nowhere" that can interrupt the main control flow at arbitrary points.

I did not discuss the cases where the target process is on the same CPU, or is in the BLOCKED state, or is inside the kernel when the signal is triggered. These cases may be the subject of another question.