Technical Linux questions

[gaf at blu.org (Jerry Feldman)]

I am not exactly certain of the Linux code since I have not checked the
kernel. On HP-UX, vfork() is an alias of fork(). On Tru64 Unix, vfork()
and fork() are separate system calles, but effectively do the same
thing. Today fork() and vfork() are implemented as copy-on-write. which
means that the parent and child processes share the same physical
virtual memory. The process creation is simply a mapping operation WRT:
memory. Certainly the child will get a new stack because of the return
value from vfork(). On the Purify project, the fork() and vfork() code
was very convoluted because on some platforms, vfork() is broken and on
others it does not actually exist, and the vfork() wrapper in libc
simply calls the fork() system call. 

Remember that a pthread_create() does not create another process. The
new thread exists in the same process space as the parent. This an
exec() system call from within a thread will replace the entire process.
I've done that. It is legal to fork() or vfork() from within a thread. 
Also, while each thread has its own priority and scheduling method, that
exists within the process' priority. 

The bottom line is that threading adds a lighter weight method for
achieving paralellism within a process. No new memory is created (except
possibly stack and thread control block). All memory (other than stack,
TCB, and TLS) is shared among all the threads. That is why many
functions in the C runtime library (such as ctime), are not threadsafe
unless the library designers have come up with a threadsafe scheme. Even
memory acquired by malloc() is available to other threads. 

And, the implementation of kernel threads varies among systems. 
 
On Sat, 22 Feb 2003 15:15:20 UTC
John Chambers <jc at trillian.mit.edu> wrote:

> True, but this doesn't  answer  the  question.   The  above
> exactly describes the original vfork(), which created a new
> process with its own stack but with the same  data  segment
> as  the  parent.  It's true that the intent was to make the
> fork+exec sequence faster by saving a copy of  memory  that
> was to be discarded. But in fact it could be used to create
> multiple control points within the same program. I did this
> on a couple of projects.  Some sync operations were needed,
> of  course,  but  that's  a  different  question  from  the
> creation  of  "threads"  and  context switching, and can be
> done in user space without any other system calls.
> 
> It's also true that vfork() is sometimes implemented as  an
> alias  of  fork().  This is rather a pity, as it interferes
> with portability.  I'd be tempted to provide an #ifdef that
> overrides vfork with a routine that creates a kernel thread
> on systems where vfork isn't implemented properly.
> 
> So far, it seems that we merely have two names for the same
> concept.   If by "vfork" you mean the original routine that
> produced a new stack but shared the rest  of  the  parent's
> memory,  there's  the question of what a kernel thread does
> that's materially different.  (And note that listing  other
> tools in a "threads" package isn't an answer. You can add a
> library of routines to anything.)
> 
> If I were to call pthread_create() followed by execve(), is
> the result any different than fork+exec or vfork+exec? On a
> system with a true vfork(), is there  any  of  the  pthread
> library's  functions  that  couldn't  be implemented?  It's
> difficult to find answers such questions in the man  pages.
> The  words  are  very  different, but they seem to describe
> something quite similar, if not identical.
> 
> One question that came up on a project:  If a process calls
> vfork() and one of the processes then does malloc(), is the
> new memory accessible to both processes?  The answer  seems
> to have been "Try it and find out." But this only tells you
> the answer on the machine you test it on; it  doesn't  tell
> you whether your code will work on another system, or after
> an upgrade on the same machine. (Actually, a bit of digging
> seems  to  turn  up  no  clear  answer to this question for
> threads, either.  Saying that malloc() is "thread safe"  is
> not  an  answer  at all, since it doesn't tell you what the
> behavior is or whether it's portable.  ;-)
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss
> 


-- 
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/d1543975/attachment.sig>