On Thu, Sep 29, 2022 at 05:45:28PM +0200, Uli Schlachter wrote: > Hi, > > Am 29.09.22 um 06:27 schrieb Keith Packard: > > Alan Coopersmith <alan.coopersm...@oracle.com> writes: > > > > > Does anyone disagree? > > > > Yeah, synchronizing with xcb seems 'obviously right. The only question > > I've got is that in 2022, should xcb ever use stubs for the thread > > functions? > > No, it shouldn't. That's why since 2017, pthread-stub just links against > pthread. It only does not do that if libc already includes the necessary > stubs. See > https://gitlab.freedesktop.org/xorg/lib/pthread-stubs/-/commit/8340ebd656c7e1a5b6d31170c1f3c87df043e793
At this point, I wonder if we should even have libpthread-stubs at all (other than for backwards compatibility), versus just *unconditionally* linking libxcb against whatever library is necessary to obtain pthreads symbols. In 2022, it *seems* like single-threaded applications are really unlikely to be bottlenecked on X protocol (rather than numerous other things through which more data will flow) to the degree that omitting locking will make the difference between them being functional and not; that's not worth the safety and correctness issues that attempting to do so introduces.