Technical Linux questions

[gaf at blu.org (Jerry Feldman)]

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>