Mike Frysinger wrote:
> On Friday 27 February 2009 15:16:45 Lennart Sorensen wrote:
> > On Fri, Feb 27, 2009 at 11:17:19AM -0500, Mike Frysinger wrote:
> > > file descriptors are not shared resources. whatever a child does with
> > > them will not affect the parent.
> >
> > I was hoping that was the case. It did seem like vfork + exac would
> > loose a lot of purpose if file descriptors weren't duplicated by vfork.
>
> yeah, it would make redirecting of std* fd's real painful (like
> daemonizing code). i didnt think vforked children having their own
> fd's would work under no-mmu until i thought about it a bit more.
> the fd indirection with the kernel can be thought of a little like a
> mmu: the real resources are translated to per-process identifiers.
You have to be very careful with vfork. Lots of things don't work
reliably and are dangerous, even if they work most of the time. Also,
code which depends on vfork behaviour isn't portable except for a few
things which are allowed.
On Linux, you can safely call most system calls in a vfork child:
- Change file descriptors with open/dup/dup2/close.
- Use fcntl F_SETFD to change the close-on-exec flag.
- Change directory with chdir/fchdir.
- setsid/setpgid etc. to manipulate terminal sessions.
- setreuid etc. to manipulate user ids for setuid processes.
- Change signal mask and signal handlers to SIG_IGN/SIG_DFL.
You should not do _anything_ with threads in a vfork child.
pthread_self() is not safe. Thread-local variables are not safe to
acccess.
(I still haven't figured out if it's safe to use vfork with shared
libraries and lazy procedure lookup... doesn't apply for Jan's ARM
with no shared libraries of course).
> (like daemonizing code)
It is possible to daemonize on uClinux without exec'ing a new process,
using clone() instead of vfork(). I have a version of the daemon()
function which does that, which I posted to the Busybox bug tracker
years ago; I should really submit it to uClibc.
-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
