Re: [PATCH v3 0/3] Add a futex interface to glibc (sys/futex.h)

Adhemerval Zanella Netto <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha
Organization Linaro
Message-ID <[email protected]>

On 25/08/26 14:46, Paul Eggert wrote:
> On 2026-08-25 09:50, Adhemerval Zanella wrote:
>> The
>> futex_timedwait supports both time_t sizes with the usual TIME_BITS=64
>> redirection
> 
> There's no backward-compatibility need for this, since it's a new glibc API. How about if this function supports only 64-bit time_t instead?
> 
> This issue is independent of what glibc does internally. Internally glibc may use helper functions that act like futex_timedwait but support 32-bit time_t, but I don't see why the 32-bit time_t functionality needs to be exposed to user apps.
> 
> At least, if there is a real need for futex_timedwait to support 32-bit time_t, that need should be explained in the patch and/or the documentation. It's confusing that some of the new API supports 32-bit time_t but other parts of it (e.g., futex_waitv) do not.

I was not fully sure about this and on my first draft I made futex_timedwait
64-bit time only. I only changed after I checked on libstdc++ code that uses
futex (libstdc++-v3/src/c++11/futex.cc and libstdc++-v3/libsupc++/guard.cc) 
and noticed that futex.cc redefine the struct timespec because the TU is not 
built with _TIME_BITS=64. I did not dig further, but I think it might be quite
complex to enable it on libstdc++.

Another reason, which I also do not have a strong opinion, is that futex does
have a 32-bit syscall (different than futex_waitv which is 64-bit only).

But it should be reasonable to only support futex_timedwait with 64-bit
time_t.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.