Date: Mon, 03 Feb 2003 10:51:28 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: rmkml <rmkml@wanadoo.fr> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: vfork / execve / accept lock Message-ID: <3E3EBA30.FB33EF1C@mindspring.com> References: <20030203155505.49450.qmail@web13407.mail.yahoo.com> <3E3E9683.801036E1@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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?3E3EBA30.FB33EF1C>