Date: Thu, 18 Feb 2016 17:32:56 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Eric van Gyzen <vangyzen@FreeBSD.org>, threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160218153256.GS91220@kib.kiev.ua> In-Reply-To: <Pine.GSO.4.64.1602171220540.24204@sea.ntplx.net> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <Pine.GSO.4.64.1602161224250.19440@sea.ntplx.net> <20160217164541.GM91220@kib.kiev.ua> <Pine.GSO.4.64.1602171220540.24204@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 17, 2016 at 12:37:52PM -0500, Daniel Eischen wrote: > On Wed, 17 Feb 2016, Konstantin Belousov wrote: > > I do plan to introduce inlined objects (most likely in the form of > > libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my > > plans are to get the existing patch for pshared into the tree for 11.0. > > After that I wanted to implement robust mutexes, still in the context of > > the libthr. Then libthr2. > > As soon as this is done, will we build FreeBSD base OS against > the new API? So only ports would be affected. I do not think this is feasible. Base system does not have any significant thread consumers, might be only ntpd qualifies. Small things like ngctl are not that important. But base system provides C++ runtime for ports and I suspect that libc++ depends on the libthr ABI. Even jemalloc depends on libthr ABI. So changing only the base ABI is probably impossible, from the first look the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this must be considered carefully during the later stage of the libthr2 development, right now it is rather empty speculation on my side. > > I was hoping to see partially inlined objects (with the first word > being a pointer to the allocated object, just like now) in for 11.0. > So by 12.0 we could make the switch over to fully inlined. I do not see how this is realistic. The issue of introducing the inlined objects is the stumbling block, regardless of their use in full or only as a placeholder for the pointer. Not even mentioning that we do not want to radically break the userspace ABI for 11.0 when the freeze is so close, we would need much more time to develop the WITH_LIBTHR2 alone. This is my opinion, but it is supported by my experience. > > If we introduce either partially or fully inlined objects for 11.1 > (with your libthr2), how does that affect our ability to move to > fully inlined by default (base & ports) for 12.0? We would not > have had a full release cycle for the ABI change. I cannot answer this question, the issue requires careful investigation, as I noted earlier in the message. Might be I or somebody else would be able to produce some trick that would ease the pain. If not, the bump of dso version numbers and dynamic linker awareness of the incompatible libraries would be to coded. > > > Finishing the current patch for 11.0 is the immediate goal, while I did > > not forget neither abandoned the inline alternative and do plan to work > > on it. That is.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160218153256.GS91220>