Thread dies during system call?

[AndrewAPrice]

How do you handle a thread or process being killed during a system call?

For example, your application calls fread to read from IO, so your thread enters the system call and waits for it to return. Meanwhile, the process is killed. How do you handle this?

[SpyderTL]

I haven't made it that far yet, but just thinking of the easiest possible solution...

Put a flag on the process and set it when it is killed. Then check the flag before swapping to a running process and just swap to the next available process instead if it is set.

Or am I over-simplifying it?

[Owen]

The process blocks in an alertable wait state. When the process receives a signal, that wait fails, you unwind the system call, and returns to userspace (except redirected to the signal handler).

How you special case SIGKILL is your choice.

[onlyonemac]

Or am I over-simplifying it?

To a limited extent because you're not removing the process from the process queue (which would be better than just "setting a flag") but yes your idea could work if you changed "setting a flag" to "removing the process from the process queue".

[sortie]

I use the design that kernel threads cannot be terminated, they can only exit voluntarily. Signals also cannot be delivered to threads when they are in kernel mode.

A request to terminate a thread is implemented as sending SIGKILL to that particular thread. If it is in user-space, the thread is terminated. If it is in the kernel, this could be dangerous, and instead a flag is set marking the thread has a pending signal. When the system call returns, the signal is delivered and SIGKILL then destroys the thread. Kernel threads could be blocking indefinitely, so the kthread_cond_wait implementation fails early if a signal is pending. The design is that kernel threads cannot block indefinitely, but can always be SIGKILLED.

[max]

Though I have no multicore support yet, I've implemented it so that if a process/thread is marked as "dead", i dont switch to it anymore, but I also dont immediately delete it. I then mark each child thread as dead. On each scheduling round I check if for dead threads and clean them up, but when a dead process comes I first check if all of its threads are dead, if they are I delete it, too. Like this the syscall can just finish its work without needing to fear that the addreess space is gone or something.

[SpyderTL]

I've implemented it so that if a process/thread is marked as "dead", i dont switch to it anymore, but I also dont immediately delete it. I then mark each child thread as dead. On each SC, sheduling round I check if for dead threads and clean them up, but when a dead process comes I first check if all of its threads are dead, if they are I delete it, too. Like this the syscall can just finish its work without needing to fear that the addreess space is gone or something.

Kind of like a garbage collector for threads?

[embryo]

Kind of like a garbage collector for threads?

Yes. I also use a cleaning thread for such purpose. It can free any resources the died thread had.

[Gigasoft]

Yes, a reaper thread is needed to destroy threads and their stacks, but the important point here is that if a thread is forcefully terminated, a system call must be able to run to its completion so that the system is not left in an broken state, Basically, Owen's answer is correct.

Fortunately, you do not have to allow for this in every place where you wait for something. It is only necessary where something could block for a long time, such as when waiting for I/O to complete. A similar situation arises when a thread is suspended (for example, if manually interrupted by a debugger), but here you don't want to disturb any running system calls, of course.