Date: Wed, 18 Jun 2008 09:44:46 +0800 From: David Xu <davidxu@freebsd.org> To: Maxim Sobolev <sobomax@freebsd.org> Cc: Ed Schouten <ed@80386.nl>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/include Makefile spawn.h unistd.h src/lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c posix_spawn.c Message-ID: <4858688E.2030404@freebsd.org> In-Reply-To: <48586652.2070204@freebsd.org> References: <200806170633.m5H6XMJH084600@repoman.freebsd.org> <20080617134828.GA30076@zim.MIT.EDU> <20080617140600.GE1176@hoeg.nl> <4857D508.8070907@FreeBSD.org> <48586652.2070204@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > I just want to make some programs to work, since Linux and Solaris > both have it now. Doing it in kernel is OK, but I don't want to put > it into the kernel until it is necessary since kernel code can not > be swapped out. ;-) > > Doing in kernel may have advantages, for example, you may get ride > of zoombie process recycling by hacking kernel, a library version > using vfork will need parent to handle SIGCHLD and recycle zoombie > process like you use popen() and system() etcs, Oops, I rethinked it, zoombie process is not a correct point. only rtld is the problem. > another advantage > is it won't involve rtld if a symbol needs to resolved, because > vfork shares same vmspace, it might block other threads in > parent process if the child process holding a rtld's > reader lock, I don't know if writer lock will be held in child, > I guess it won't be. if the child process get killed wrongly > by someone, it might hold reader lock forever, this is the race > condition. a kernel version may have trouble if something can not > be easily done in kernel, though I didn't find the one can not > be done in kernel at present. > > Regards, > David Xu > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4858688E.2030404>