I was currently considering

leaving the compile-time flag as is
if it is not set, use yet another environment variable at run-time to activate or deactivate the "forced monotonic fix", or auto-sense otherwise.

As far as testing is concerned, first without any auto-sensing: Assuming there's a 50:50 chance that it is working correctly already as compiled (one either set the compile-time flag appropriately or did not), there are still two ways to fail: It can either hang (compile-time flag not set, but necessary), or pthread_cond_timedwait delivers a wrong return value (compile-time flag set, but not necessary). The test program itself cannot detect the later kind of error yet (it actually expects ETIMEDOUT to be returned) and probably would have to be replaced by a more complex test that controls a multi-threaded test program from outside. So getting it not to hang is quite easy, but can be misleading in 25% of all cases. That's why we said "try without the compile-time flag first, and only if it hangs, recompile with the flag".

So it comes back down to good auto-sensing. Your suggestion to auto-decide for yes with glibc > 2.30 seems reasonable, but looking back at the issues here related to the introduction of the compile-time flag, we actually introduced it for older glibc versions (e.g., #205 about glibc 2.17, #208 about Debian 8). We then investigated the relationship to different architectures (in #287), but that might as well have been about different glibc versions as well without us noticing?! We shortly discussed whether it may be related to that, but did not investigate closer.

But in sum, I think auto-sensing to no for glibc =< 2.30 might break things for older systems. So it'd probably have to be a range of affected glibc versions.

Looking at #335 indicates that more trouble will come with glibc 2.31 on non-x86_64 and glibc 2.33 in general. Those are actually more related to unhandled futex()-like calls and, yet again, syscall() stuff, but result in the same kind of hangs due to faked / non-faked confusion between the application and glibc-internals. My guess is that we might need some sort of a look-up table to determine for which combination of glibc version and platform we actually need the "forced monotonic fix" within which intercepted system calls. Testing with locally compiled glibc versions on a specific platform, as you suggested, might be a small first step. But compared to the effort required to get a complete picture, manually setting a compile-time flag currently does not seem that horrible for the moment. So I wonder whether it's a good plan to do the auto-sensing now, limited to pthread_cond_timedwait, or postpone hoping for a more generic solution.

Please consider a 0.9.10 release #366

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions