Date: Sun, 27 Dec 2015 01:44:24 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, freebsd-arch@freebsd.org, freebsd-threads@freebsd.org Subject: Re: libthr shared locks Message-ID: <20151226234424.GJ3625@kib.kiev.ua> In-Reply-To: <Pine.GSO.4.64.1512261151550.19056@sea.ntplx.net> References: <20151223172528.GT3625@kib.kiev.ua> <4199356.DlQeWDh27F@ralph.baldwin.cx> <Pine.GSO.4.64.1512240836460.9582@sea.ntplx.net> <5496837.TbTQtANDNj@ralph.baldwin.cx> <Pine.GSO.4.64.1512241338340.10649@sea.ntplx.net> <20151224191408.GA3625@kib.kiev.ua> <Pine.GSO.4.64.1512251310090.14902@sea.ntplx.net> <20151226105409.GH3625@kib.kiev.ua> <Pine.GSO.4.64.1512261151550.19056@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 26, 2015 at 12:15:43PM -0500, Daniel Eischen wrote: > I think libthr has always done that (postpoining until critical > section is exited). But there are libc (and perhaps other) > locks that may be left locked on a fork(). Really (according > to POSIX), a fork() from a threaded program can only be used > to exec() something. libthr only started to do the interception in r212076, which was committed by David on Sep 1, 2010. Posix left the behaviour undefined after the fork, but real world rejects implementations which make C runtime broken after fork in mt process. Rtld must work in the child anyway (and in sighandler as well). We were forced to ensure also that malloc(3) and pthread_create(3) work in the child after the fork, and any transient regressions in this area where immediately reported. One of the biggest abusers of that are Qt/KDE. > I guess I am just not that worried about the ABI change when combined > with a library version bump. We use to do this for every new major > release, it isn't anything that hasn't been done before. We never > supported 2 thread libraries in the same executable, and it is > obvious when that happens (I think we even instrumented libc_r, > or was it rtld?, to emit a warning when that happened. My memory > is fuzzy). With poudriere, our new package system, I would think > we would be better off now than 10 years ago? We did significant work to avoid requiring complete recompilation of all user binaries on the major version updates. Part of it is the symbol versioning, another part is the stronger discipline and future planning when doing ABI-sensitive changes. At least starting with stable/8, when you binary depends only on the basic C runtime (i.e. rtld + libc + libm + libthr), you are no longer required to recompile it, and you do not need to install any compat libraries. Things just work. We are not there yet, since some libraries are not managed that good, e.g. libutil is not symver-ed but at least usually bumped correctly. Some libraries are handled much worse, e.g. libcam _interface_ depends on volatile kernel parts and libcam version is not always bumped when needed. Unfortunately, libcam is the dependency of high-profile user applications, from Gnome and KDE. This is what prevents us from stopping declaring 'recompile ports on major upgrade', but it is a goal. Still, basic C runtime is in much better shape WRT ABI stability than it was, say, in the 6.x-7.x time. This is why ino_t 64bit is moved with so much caution, and should also explain why I am so nervous to lock inlining. Doing libthr bump would break things. > > I do note that I was initially wrong in thinking that port revision > bumps could help alleviate any pain. A port could be built in > -stable with the revision bump just as well as in -current (or 11). > What would be needed is for pkg to understand that any port built > for 10 and previous could not run on 11+ (just to be on the safe > side). BTW, I tried to explain exactly this scenario in one of the previous replies. > > > OTOH, we should be able to plan such change, which requires much more > > drastic measures to be implementable. I started thinking about it, and > > I noted that what is needed is solved by renaming libthr to something > > else, e.g. libthr2. One of the issue which is not solved by the dso > > version bump (not to even mention versioned symbols bump) is the > > static linker bringing both libthr.so.3 and libthr.so.4 into the same > > process, by the mere use of -lpthread by different objects at different > > times. Then, libthr and hypothetical libthr2 should check and prevent > > activation of image which loads both. > > > > But these are longtime to evaluate and implement. The feature at hand > > does not require ABI change, as my patch demostrated. Yes, shared > > mutexes would be more naturally implemented with the inline locks, and > > avoidance of an indirection in the libthr is also good, but lets not mix > > significant ABI change and some less ambitious feature. My approach does > > not lock out future strategies. > > I agree, but the work that you are doing now would be basically > thrown out later on. I will not stand in your way and appreciate > any work you do. I would just rather that the struct change be > made now for 11, even without any pshared or other changes. For > once the struct change is made, pshared or other additions can > be made afterward, even in the 11 branch because they would not > break the ABI. Lock inlining was not done for ten years, now cost of doing it is extremely high, as discussed above. Who would drive the change, and with what time frame ? If me, I seriosly consider renaming libthr to libthr2, but I had no time to think much about it. Right now, I think that I want to commit my current patch and implement robust mutexes as the next step, without ABI breakage. At least, this seems to have fixed time-frame and can be made ready for 11.x. Lock inlining might be not. Are there serious objections against the plan, except that (lock inlining + pshared) is ideal situation, while the plan is not (but more practical) ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151226234424.GJ3625>