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.