From: Adhemerval Zanella <firstname.lastname@example.org> To: Peter Zijlstra <email@example.com>, Sebastian Andrzej Siewior <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, "Andrey Semashev" <email@example.com>, firstname.lastname@example.org, email@example.com, "Davidlohr Bueso" <firstname.lastname@example.org>, "Peter Oskolkov" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "Ingo Molnar" <email@example.com>, "Darren Hart" <firstname.lastname@example.org>, email@example.com, "Steven Rostedt" <firstname.lastname@example.org>, "André Almeida" <email@example.com>, "Thomas Gleixner" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "Nicholas Piggin" <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v4 00/15] Add futex2 syscalls Date: Tue, 8 Jun 2021 15:08:44 -0300 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YL99cR0H+7xgU8L1@hirez.programming.kicks-ass.net> > All the attempts with API extensions didn't go well because glibc did > not want to change a bit. This starts with a mutex that has a static > initializer which has to work (I don't remember why the first > pthread_mutex_lock() could not fail with -ENOMEM but there was > something) and ends with glibc's struct mutex which is full and has no > room for additional data storage. Yes, we have binary compatibility constraints that prevents us to simply broken old binaries. This is quite true for static initialization, which imposes even harder constraints, different than the pthread_mutex_t size where we can workaround with symbols versioning. But even then we hear from users that out pthread_mutex_t is still way larger, specially for fine grained locking so I am not sure if we do want to extend it. > That said; if we're going to do the whole futex-vector thing, we really > do need a new interface, because the futex multiplex monster is about to > crumble (see the fun wrt timeouts for example). > > And if we're going to do a new interface, we ought to make one that can > solve all these problems. Now, ideally glibc will bring forth some > opinions, but if they don't want to play, we'll go back to the good old > days of non-standard locking libraries.. we're halfway there already due > to glibc not wanting to break with POSIX were we know POSIX was just > dead wrong broken. > > See: https://github.com/dvhart/librtpi You are right, we don't really want to break POSIX requirements in this regard because users constantly come with scenarios where they do expect our implementation to be conformant . And even now, there are case we don't get it fully right  and it is really hard to fix such issues. If I recall correctly from a recent plumber couple of years ago about the librtpi, the presents stated their implement do not follow POSIX standard by design. It suits then for their required work, but it is not what we really aim for glibc. We *might* try to provide as an extension, but even then I am not if it would be fully possible due API constraints. So, regarding the futex2 we might try to support it eventually; but if this newer interface is not a really a superset of futex1 we won't put much effort. Supporting newer syscall requires an extra effort from glibc, we need to keep fallback for older ones in case the kernel is too old and it also imposes runtime costs. Also currently we don't have a specific usage. The proposed patch to add the 'pthread_mutex_lock_any' and 'pthreada_timedlock_any'  also did not gave much detail in realword usages or how it can be leveraged.  https://sourceware.org/bugzilla/show_bug.cgi?id=13165  https://sourceware.org/bugzilla/show_bug.cgi?id=25847  https://sourceware.org/pipermail/libc-alpha/2019-July/105422.html
next prev parent reply other threads:[~2021-06-08 18:09 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-03 19:59 André Almeida 2021-06-03 19:59 ` [PATCH v4 01/15] futex2: Implement wait and wake functions André Almeida 2021-06-03 19:59 ` [PATCH v4 02/15] futex2: Add support for shared futexes André Almeida 2021-06-03 19:59 ` [PATCH v4 03/15] futex2: Implement vectorized wait André Almeida 2021-06-03 19:59 ` [PATCH v4 04/15] futex2: Implement requeue operation André Almeida 2021-06-03 19:59 ` [PATCH v4 05/15] futex2: Implement support for different futex sizes André Almeida 2021-06-04 0:23 ` kernel test robot 2021-06-06 19:12 ` Davidlohr Bueso 2021-06-06 23:01 ` Andrey Semashev 2021-06-03 19:59 ` [PATCH v4 06/15] futex2: Add compatibility entry point for x86_x32 ABI André Almeida 2021-06-03 19:59 ` [PATCH v4 07/15] docs: locking: futex2: Add documentation André Almeida 2021-06-06 19:23 ` Davidlohr Bueso 2021-06-03 19:59 ` [PATCH v4 08/15] selftests: futex2: Add wake/wait test André Almeida 2021-06-03 19:59 ` [PATCH v4 09/15] selftests: futex2: Add timeout test André Almeida 2021-06-03 19:59 ` [PATCH v4 10/15] selftests: futex2: Add wouldblock test André Almeida 2021-06-03 19:59 ` [PATCH v4 11/15] selftests: futex2: Add waitv test André Almeida 2021-06-03 19:59 ` [PATCH v4 12/15] selftests: futex2: Add requeue test André Almeida 2021-06-03 19:59 ` [PATCH v4 13/15] selftests: futex2: Add futex sizes test André Almeida 2021-06-03 19:59 ` [PATCH v4 14/15] perf bench: Add futex2 benchmark tests André Almeida 2021-06-03 19:59 ` [PATCH v4 15/15] kernel: Enable waitpid() for futex2 André Almeida 2021-06-04 4:51 ` [PATCH v4 00/15] Add futex2 syscalls Zebediah Figura 2021-06-04 17:04 ` André Almeida 2021-06-04 11:36 ` Nicholas Piggin 2021-06-04 20:01 ` André Almeida 2021-06-05 1:09 ` Nicholas Piggin 2021-06-05 8:56 ` Andrey Semashev 2021-06-06 11:57 ` Nicholas Piggin 2021-06-06 13:15 ` Andrey Semashev 2021-06-08 1:25 ` Nicholas Piggin 2021-06-08 11:03 ` Andrey Semashev 2021-06-08 11:13 ` Greg KH 2021-06-08 11:44 ` Peter Zijlstra 2021-06-08 14:31 ` Davidlohr Bueso 2021-06-08 12:06 ` Andrey Semashev 2021-06-08 12:33 ` Greg KH 2021-06-08 12:35 ` Greg KH 2021-06-08 13:18 ` Andrey Semashev 2021-06-08 13:27 ` Greg KH 2021-06-08 13:41 ` Andrey Semashev 2021-06-08 17:06 ` Zebediah Figura 2021-06-08 14:14 ` André Almeida 2021-06-07 15:40 ` André Almeida 2021-06-08 1:31 ` Nicholas Piggin 2021-06-08 2:33 ` Davidlohr Bueso 2021-06-08 4:45 ` Nicholas Piggin 2021-06-08 12:26 ` Sebastian Andrzej Siewior 2021-06-08 14:23 ` Peter Zijlstra 2021-06-08 14:57 ` Sebastian Andrzej Siewior 2021-06-08 15:04 ` André Almeida 2021-06-08 18:08 ` Adhemerval Zanella [this message] 2021-06-08 18:19 ` Florian Weimer 2021-06-08 18:22 ` Adhemerval Zanella 2021-06-09 16:26 ` David Laight
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v4 00/15] Add futex2 syscalls' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).