Messages in this thread | | | Date | Fri, 11 Jul 1997 18:15:58 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: kernel_thread () |
| |
Date: Thu, 10 Jul 1997 12:46:04 +0530 (GMT+0530) From: Chirayu Patel <chirayu@idc.tandem.com>
I am currently developing a BSD sockets like interface within the Linux kernel, so that it can be easier to embed application layer protocols within the kernel. This will enable to make dedicated Linux servers, dedicated for speed. (Please do not argue on this...I might be wrong...the main purpose of this exercise to know more about the Linux kernel)
I suspect the reason why no one sent you a reply is becuase (a) you're proposing to do something which most experienced kernel programmers would say is a bad thing, and then (b) you said, please do not argue with me on this.
So I said, "OK", and deleted your e-mail message.
The bottom line is that the kernel programming environment is very different from the user programming environment; this is not surprising, given that it is the kernel that provides services such as "signals". So you don't have signal handlers in a kernel thread; kernel threads are non-preemptible (this means that if a kernel thread gets into an infinite loop, the entire system grinds to a halt). If you have kernel code that wants to be "interrupted" by a signal, it is the kernel's code responsibility to periodically check current->signal.
- Ted
| |