[Xcb] [PATCH pthread-stubs 0/4] Rework pthread-stubs design/implementation

[Jamey Sharp]

I haven't thought about this very hard, or reviewed the actual
patches, or contributed anything to XCB for years... but for what it's
worth:

I have no objection to plan #1. It was probably hubris to think we
could match the system's thread implementation in any meaningful way.
It has worked better than it had any real right to, but as you say,
that's mostly because on most installations pthread-stubs didn't have
to do anything at all.

On the other hand, I think plan #2 would be pretty unfortunate. I
think it would impose a measurable performance penalty for the
majority of users, since nobody's going to want to do the
stubs-detection magic in their configure scripts, so they'll just link
against full pthreads even on systems where they don't need to.

So there's my two cents.
Jamey

On Thu, Nov 3, 2016 at 1:24 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi all,
>
> A recent change (commit fa6db2f9c01 - list.m4: Add some new pthread symbols)
> lead to an interesting bugreport [1] which makes me think that the current
> pthread-stubs design isn't as robust (broken?) as one would expect.
>
> In brief: if there is a pthread-stubs library, one can end up using a
> mismatched API - if one uses dlopen with a binary which pulls a full pthreads
> implementation. That is because the weak symbols, as provided by the
> pthread-stubs DSO, get overridden.
>
> This has gone unnoticed because a) on most platforms pthread-stubs never
> creates a DSO and in the rare case where it does b) it's very uncommon to
> dlopen a binary which pulls a non-lightweight pthreads symbols, from a
> pthreads-stubs (linked) one.
>
>
> The only solutions that I can think of are:
>  1) make pthread-stubs "meta package" who's Cflags/Libs expand to the platform
> specific PTHREAD_{CFLAGS,LIBS} if the runtime does not provide lightweight
> pthread symbols, or
>  2) "kill off" pthread-stubs and let everyone
>  - handle the "do I need to link against pthreads or not" in their configure.ac
>  - link against the complete/full pthread API
>
> Imho 2) is rather selfish/overzealous so I've went ahead and tackled 1).
>
> Note: 1/4 a standalone fix which can be applied independently of how the
> direction/discussions reached.
>
> The remaining patches can be squashed or kept separate, based on how things go.
>
> Regards,
> Emil
>
> Cc: Rob Clark <robclark at freedesktop.org>
> Cc: Ben Widawsky <ben at bwidawsk.net>
> Cc: Uli Schlachter <psychon at znc.in>
> Cc: Josh Triplett <josh at freedesktop.org>
> Cc: Jamey Sharp <jamey at minilop.net>
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=98048
>
> Emil Velikov (4):
>   autogen.sh: quote path variables
>   Revert "list.m4: Add some new pthread symbols"
>   Rework the pthread-stub design
>   configure: drop various AC_macros
>
>  Makefile.am         |  10 --
>  README              |  33 +++-
>  autogen.sh          |   6 +-
>  configure.ac        |  69 ++++----
>  list.m4             |   3 -
>  m4/ax_pthread.m4    | 485 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  pthread-stubs.pc.in |   3 +-
>  stubs.c.m4          |  91 ----------
>  8 files changed, 548 insertions(+), 152 deletions(-)
>  create mode 100644 m4/ax_pthread.m4
>  delete mode 100644 stubs.c.m4
>
> --
> 2.10.0
>