Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Kostik Belousov
On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote: Seems this interface be acceptable ? Looks good to me. The proposed code changes are in the attached patch. Proposed wording of addition into RFORK(2): Below is the patch I intend to commit after you retest it. I added the

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Petr Salinger
Seems this interface be acceptable ? Looks good to me. The proposed code changes are in the attached patch. Proposed wording of addition into RFORK(2): DESCRIPTION: RFTSIGZMB If set, the kernel will return selected signal number instead of SIGCHILD upon thread exit

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Petr Salinger
Below is the patch I intend to commit after you retest it. I applied it against our 8.2 based package, altered our clone to use this new interface and run eglibc testsuite. No regression. Our runtime detection of this new interface will be based on sysctl kern.osreldate. some rewording to

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Kostik Belousov
On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote: Below is the patch I intend to commit after you retest it. I applied it against our 8.2 based package, altered our clone to use this new interface and run eglibc testsuite. No regression. Our runtime detection of this new

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Robert Millan
2011/7/12 Kostik Belousov kostik...@gmail.com: I just committed this to HEAD. Will MFC in a week, unless some problems arise. Thanks! I will bump revision for stable/8 when merging, but I do not see much reason to bump on HEAD right now. Uhm I think we can survive without a bump in HEAD.

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Petr Salinger
I will bump revision for stable/8 when merging, but I do not see much reason to bump on HEAD right now. Many thanks. Uhm I think we can survive without a bump in HEAD. For now we will need to keep our backward-compatibility patch anyway, and when the bump happens on stable/8 our sysctl

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Kostik Belousov
On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote: I will bump revision for stable/8 when merging, but I do not see much reason to bump on HEAD right now. Many thanks. Uhm I think we can survive without a bump in HEAD. For now we will need to keep our backward-compatibility

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote: This patch made by Petr Salinger improves compatibility with LinuxThreads in rfork() syscall. The Linux clone() implementation allows specifying the signal sent to parent when child terminates (instead of SIGCHLD). As the

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote: Can you, please, describe the reasoning behind the + if (sig == SIGCHLD) sig = 0; line ? The main reason is backward compatibility. The original FreeBSD code allows only to select between SIGUSR1 or SIGCHLD signals.

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote: RFLINUXPTH was used by the linuxthreads port, that was popular in the time of FreeBSD 4.x and may be 5.x to run mysql. I will object against this breakage. Do I understand correctly that API/ABI backward compatibility with

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Robert Millan
2011/7/11 Kostik Belousov kostik...@gmail.com: I shall state that the sig == SIGCHLD case is ugly. Having the separate flag do not send signal to the parent would be much less clumsy. What are the requirements for the ABI stability for Debian/kFreeBSD ? Can this be fixed now, or is it too late

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
RFLINUXPTH was used by the linuxthreads port, that was popular in the time of FreeBSD 4.x and may be 5.x to run mysql. I will object against this breakage. Do I understand correctly that API/ABI backward compatibility with previous FreeBSD releases w.r.t RFLINUXPTH is needed ? The 1st patch

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
Can you, please, describe the reasoning behind the + if (sig == SIGCHLD) sig = 0; line ? The main reason is backward compatibility. The original FreeBSD code allows only to select between SIGUSR1 or SIGCHLD signals. The our extension changes meaning of RFLINUXTHPN to select

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
The 1st patch satisfies this. I agree that SIGCHLD part is not easily readable. The SIGCHLD part is ugly. This is why I am asking about possible ways to overcome this. We need a way to specify no signal. It can be new flag or ugly SIGCHLD. new flag: pros: cleaner design cons: one bit of

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote: The 1st patch satisfies this. I agree that SIGCHLD part is not easily readable. The SIGCHLD part is ugly. This is why I am asking about possible ways to overcome this. We need a way to specify no signal. It can be new flag or

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
I would instead use a new flag to specify a signal sent on the child death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is set, the bit slice is used as signal number, 0 means do not send any signal. Please note that the signal should be checked for validity, it must be =

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote: I would instead use a new flag to specify a signal sent on the child death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is set, the bit slice is used as signal number, 0 means do not send any signal. Please note

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Petr Salinger
Should the bit slice be 7 or 8 bits ? I propose to go 8 bits, and add the check to be future-proof. It seems that we already parse GNU/kFreeBSD brandnote. I think this could be used to distinguish between old behaviour, that is currently used by your libc, and proposed new interface, if

Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Kostik Belousov
On Mon, Jul 11, 2011 at 08:05:56PM +0200, Petr Salinger wrote: Should the bit slice be 7 or 8 bits ? I propose to go 8 bits, and add the check to be future-proof. It seems that we already parse GNU/kFreeBSD brandnote. I think this could be used to distinguish between old behaviour, that is