Date: Tue, 04 Feb 2003 11:39:27 +0100 From: rmkml <rmkml@wanadoo.fr> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vfork / execve / accept lock Message-ID: <3E3F985F.ED36E85C@wanadoo.fr> References: <20030203155505.49450.qmail@web13407.mail.yahoo.com> <3E3E9683.801036E1@wanadoo.fr> <3E3EBA30.FB33EF1C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank for you answer. It is difficult to find anything concerning the signal model of BSD implementation. In particular, for threaded applications. If you can give me some advise or documentation to read, it will be very helpfull to me . In the first part of the answer, do you want to say that a threaded application can't use vfork/fork/rfork command because the result will be undefined ? In this case is there a solution to launch external cmd ? In your opinion, can directly the application create a new thread, this thread used execve, and the parent thread waitpid() ? Thank you in advance. Bests regards. Terry Lambert wrote: > rmkml wrote: > > here is a sample code (vfork_execve.c) to demonstrate a locking problem. > > The short answer is that your code is wrong. > > The longer answer is that your code is assuming implementation > details in vfork() which are undefined in threaded programs, > according to the standard, and is assuming that the threads > implementation is in the kernel, and assuming that the threads > are created via a process similar to vfork(). > > Since the standard permits implementations to be in user space, > and fork interaction is undefined, and signal delivery targeting > is undefined, you should probably expect that any threaded > program using signals or using fork/vfork/rfork will exhibit > undefined behaviour. > > For example, the pthreads implementation on AIX will not end up > delivering the signal to the expected thread, either. This was > a bug in MySQL on AIX, for a while. I can't remember if it was > me, Mark Peek, Paul Ozzello, or Jenifer Meyers that fixed the > assumption, and sent the patch off to the MySQL folks, but it > was one of us. > > FWIW, it's also incorrect to expect PTHREAD_SCOPE_SYSTEM to work > on a user space pthreads implementation, which is permitted by the > standard. > > It's also illegal set up your signal handler the way you have, > given that the standard specifically states that it's unsafe to > call some function in signal handlers, and you call one of them; > realize that any system call you make will actually get the libc_r > wrapped version, and therefore it should not be called in a signal > handler in a threaded program, unless it's specifically allowed. > > Finally, signals are persistent conditions, not events. If you > intend to write code where reaping your SIGCHLD handler, you > *will* have to loop, as you do, on waitpid, following receipt of > the signal, but the waiting should be accomplished via the signal > handler setting a global volatile flag, and then the flag should > be checked in the main loop of the program or a thread, somewhere, > and the waitpid called from there. > > If you want to signal specific threads, you need to trampoline > the signal from the process scope to a particular thread scope, > using pthread_kill() after receiving the signal (this was the AIX > MySQL fix). > > -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3F985F.ED36E85C>