This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Implement __libc_single_threaded support

* Rich Felker:

> On Mon, Feb 04, 2019 at 07:54:09PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>> > So all your optimization is doing is saving one level of indirection
>> > for access from shared libraries. It does not save any expensive setup
>> > for PC-relative access on archs where it's expensive.
>> That's correct.  I'd like to hear the point of view of architecture
>> maintainers on this matter.
>> I can prepare a patch using just one variable if someone wants to run
>> actual performance measurements.  Other aspects of the complexity will
>> remain, though.  I don't think the thread counter should be read
>> directly, but rather an infrequently updated variable, as in the current
>> patch.  Registration would go away, but the complicated rules for
>> updates of the single-threaded indicator in statically linked processes
>> which use dlopen would remain.
> I don't see how dlopen is involed at all once there's no more per-DSO
> data object. The only complexity is synchronization around the change
> from 1->0 or 0->1 when threads are created or exit.

With static dlopen, there would still be two variables because the
static variable does not interpose the definition on the dynamic side.
(The dlmopen case also needs some more work, I just realized, due to the
current duplication of the __nptl_nthreads variable.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]