Domains — Signals & Threads

Domains vs. Unix Threads & Signals

This seems like a good thread nexus. A Linux Threads goldmine. my intro to threads

Generalities on Threads

There are two kinds of threads about and I don’t know how consistent the nomenclature is at making the distinction. I will call the two Kernel threads and user threads here until I get convincing information. These distinctions make sense only in a Unix context.

Kernel Threads
- A kernel thread is mainly a construct of the kernel. (Sometimes called a LWP, or Light Weight Process)
- Two processors running in the same “process” require kernel threads.
- Thread switching can take place between arbitrary instructions.
User Threads
- User code arranges for switching and the kernel is unaware of what thread is running
- The kernel is uninvolved except for
  - providing for non-blocking calls to kernel functions that require some asynchronous physical facility beyond the CPU. Disk and network IO and two important examples.
  - providing interrupts (signals) to the process so that the calculation awaiting the completion of the asynchronous service.
- Thread switching is done explicitly by user mode code.

Here is a good description of the current state of Linux threads which would be called Kernel Threads in this note. Some information is also available there about Posix threads.

Keykos seems awkward at duplicating the Unix style of thread.

On Solaris “man -s 5 signal” reveals that signals are directed to a process, not a thread and that the kernel may select which threads is to be diverted to the task. Furthermore if this thread is “blocked” on a system call that that call will be aborted. This does not seem like a friendly programming environment. I see no guidence on which calls may block.

I can only imagine the following situation: There is some code that needs to run upon the asynchronous signal. I am at a loss as to why one of the current tasks is commandered to do the job.