From: Joe deBlaquiere (jadb@redhat.com)
Date: Mon Jan 22 2001 - 10:10:38 EST
We have been down this path before, and quite exhausted the possibility of doing a real fork. Are the uclinux@c3po.kc-inc.net mail archives available anywhere so we can point to them? And I don't care if you want to make a MP3 player out of your uCsimm, please feel free to, but please take your discussion elsewhere (it is equally exhausted). koenraad.devleeschauwer@lid.kviv.be wrote: > At this moment, uClinux implements vfork() instead of fork. > In vfork(), child and parent share the same data and stack. > This implies the child should > - be careful not to modify data in the parent process. > - not return from the function where vfork() was called. > Some software would be easier to port to uClinux if uClinux had a real fork() instead. > > I've been experimenting with a wrapper around vfork() which does the following: > > - Before forking: > - make a backup copy of the parents' data and bss segments. > - make a backup copy of the parents' malloced data. > - make a backup copy of the parents' stack. > > - After forking: > - In the child process: > - Silently ignore any request by the child process to free data > malloced by the parent. The child process is allowed to free data > malloced by itself only. > > - In the parent process, after the child has exec()ed or _exit()ed: > - restore backup copy of the data and bss segments. > - restore backup copy of the malloced data. > - restore backup copy of the stack. > > This results in very fork()-like behavior. The main differences between the > above and a real fork are: > - The parent still is blocked until the child execs or _exits. > - The parent does not process any signals until the child has exec-ed or exited. > > The cost of the above seems to be reasonable. As an example, > a fork in bash results in about 100k additional memory being allocated before > the parent forks (and freed after the child has exec-ed). > > bash-2.04# wc /etc/rc > nfork: forking, 20758 bytes in 421 mallocs, stack 358 bytes, heap 87245 bytes. > 12 42 327 /etc/rc > bash-2.04# exit > > The downside is that I've implemented all of this in userland, and in retrospect > this seems to have been a poor choice. Especially saving and restoring the > stack is very tricky in userland. > > Has anyone else experimented along similar lines? Implemented something > like this in the kernel? What did it look like? > > koen > > This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/ -- Joe deBlaquiere Red Hat, Inc. 307 Wynn Drive Huntsville AL, 35805 voice : (256)-704-9200 fax : (256)-837-3839 This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/
This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:27 EDT