Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
I think that Nathan did a decent job, but did not really answer the why. First, user threads do not posess the capability to run in multiple CPUs. Kernel threads provide this capability. As I mentioned in my earlier post, on Tru64 Unix, for a threaded application, they allocate one kernel thread per available CPU, and the user threads are mapped to the kernel threads as necessary. While vfork() was intended to be followed closely by an exec() call on a virtual memory system, today vfork() and fork() are commonly implemented as effectively the same call. WRT: Threads. Unlike a fork(), a thread is created by a thread create function (eg. pthread_create() for POSIX threads). It operates within the process space of the caller, so that no memory needs to be allocated (except possibly for the thread's stack and a control block). Also, context switching in threads is generally less expensive. We also need to consider that the thread model is portable to other operating systems, such as VMS, Windowz, et. al. where fork()/vfork() is primarily a Unix paradigm. On Sat, 22 Feb 2003 04:49:42 UTC John Chambers <jc at trillian.mit.edu> wrote: > Which reminds me of a question I've never really seen > answered: How exactly do kernel threads differ from the > result of a vfork() call? > > If a kernel thread gets its own pid, and shares memory with > the parent, that's exactly what vfork() did in the systems > that had it. Is "kernel thread" just a fancy new name for > an old idea? > > (One difference seems to be that documentation on threads > is a lot more confused and ambiguous, making it difficult > to determine exactly how they behave. ;-) -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.blu.org/pipermail/discuss/attachments/20030222/af29ef61/attachment.sig>
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |