Date: Thu, 16 Nov 2000 08:47:58 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Satoshi - Ports Wraith - Asami <asami@FreeBSD.org> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, stable@FreeBSD.org, roger@FreeBSD.org Subject: Re: libc shlib version Message-ID: <Pine.SUN.3.91.1001116081615.14919A-100000@pcnet1.pcnet.com> In-Reply-To: <vqchf586psc.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Nov 2000, Satoshi - Ports Wraith - Asami wrote: > * From: Daniel Eischen <eischen@vigrid.com> > > * > Roger's packages is a different issue, that one was in libc_r. > * > According to him, it was caused by the pthread merge that occurred too > * > late for him to fix his ports before the (initial) ports freeze. > * > > * > Hmm. Now that I think about it, since this one is a pure > * > backward-incompatible library interface change, do we need to bump > * > libc_r's version number? > * > * IMO, no. The change to libc_r was to fix a deficiency/bug. I > * can tell you the exact problem if you're interested. > > Roger said it breaks precompiled binaries, meaning if you do a make > world, the new libc_r will not be compatible with some of the old > binaries. This is true, but only because those applications were improperly coded. They didn't really rely on the bug being present; it was more that they didn't know that the process could be signaled under certain conditions. > That sounds like a situation where we need the libc_r shlib version to > protect us from, no? In general, I don't think we want to bump library versions for bug compatability reasons - there'd be a lot of version bumps then, wouldn't there? Since there hasn't been a synopsis of what the problem really is, I'll provide it in case anyone is really interested. The relevent paragraph in the POSIX spec is: B.3.3.10 Send a Signal to a Thread The pthread_kill() function provides a mechanism for asynchronously directing a signal at a thread in the calling process. This could be used, for instance, by one thread to effect broadcast delivery of a signal to a set of threads. Note that pthread_kill() only causes the signal to be handled in the context of the given thread; the signal action (terminating or stopping) affects the process as a whole. There's also a section on sigwait() which basically says that if no signal handler is installed, then sigwait effectively installs a signal handler for the signals in the waitset. This means that if a thread calls pthread_kill() and the signal action for the process is SIG_DFL (no installed signal handler, no threads waiting for the signal in sigwait, and the signal action is not SIG_IGN), then the signal gets sent to the process as well as being marked pending in the target thread. Previously, our threads library wouldn't send the signal to the process in this case. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1001116081615.14919A-100000>