* signals, syscalls and schedule()
@ 2016-11-25 2:32 zerons
0 siblings, 0 replies; only message in thread
From: zerons @ 2016-11-25 2:32 UTC (permalink / raw)
To: kernelnewbies
Hi all.
I have several doubts about signals and syscalls.
When a signal handler gets involved?
About signal, I think I have figured it out, maybe?
I checked the source code, and found that when call `prepare_exit_to_usermode`
-> `exit_to_usermode_loop`, then `do_signal` gets involved. So when switch to
user mode, the signal handler get called before restart the syscall if needed.
That means when return from a syscall or the process scheduled, we could handle
the signal.
Interruptible syscalls, they check the process signal state by themselves and
return -ERESTARTSYS or -EINTR, is that why we call them interruptible syscalls?
When a syscall running, and then the time slice runs out, does it switch to a
new process or wait until the system call returns? If switch to a new process,
when the interrupted process runs again, is it still in kernel mode to finish
the syscall? Is that to say, a signal is handled when return from a syscall or
the process scheduled and it is in usermode?
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-11-25 2:32 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-25 2:32 signals, syscalls and schedule() zerons
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).