Unix Threads & Signals
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.
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.
- 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.
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.