This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: HAVE_CLOCK_GETTIME not repected in pytime.c
Type: compile error Stage: resolved
Components: Interpreter Core Versions: Python 3.8
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: benjamin.peterson, iritkatriel, jerome.hamm, pmpp, python-dev, vstinner
Priority: normal Keywords: patch

Created on 2020-04-03 15:30 by jerome.hamm, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 19374 closed python-dev, 2020-04-04 21:36
PR 19385 open python-dev, 2020-04-05 13:21
Messages (10)
msg365703 - (view) Author: Jérôme (jerome.hamm) * Date: 2020-04-03 15:30

In the file Python/pytime.c (line 886 and others), functions and constants that I infer should be declared by HAVE_CLOCK_GETTIME are called without #ifdef.

Best regards,
msg365712 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2020-04-03 17:49
Does this cause a problem? At this point, it might be preferable to just assume clock_gettime exists on POSIX systems.
msg365751 - (view) Author: Jérôme (jerome.hamm) * Date: 2020-04-04 08:56
Hold on, this was the case with Python 3.8.2, but I just checked Github and the code is different! I'll have to check again with HEAD, and sorry if it was fixed!

"Drop your panties sir William, I cannot wait till lunchtime".
msg365758 - (view) Author: Jérôme (jerome.hamm) * Date: 2020-04-04 10:43
OK, I was looking at the wrong line numbers, the problem is still there and as follows.
You might call me a perfectionist, but if HAVE_CLOCK_GETTIME is not defined, the function pytime_fromtimespec is taken out by the preprocessor, but still called  by the function pymonotonic, so python does not compile.
I'm thinking of two ways to go, either stop configure if HAVE_CLOCK_GETTIME is not defined, or rewrite the function differently (I don't know how badly a truly monotonic clock is needed).
It does feel strange to me to partially only honor HAVE_CLOCK_GETTIME.

"With government backing, I could make it very silly"
msg365775 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-04 19:35
Python has a long history (30 years). time.time() had multiple implementations. When I added time.monotonic() in Python 3.3, it was optional. I changed that in Python 3.5: time.monotonic() is now always available.

time.monotonic() has multiple implementations:

* Windows: GetTickCount64()
* macOS (Darwin): mach_absolute_time()
* HP-UX: gethrtime()
* Solaris: clock_gettime(CLOCK_HIGHRES)
* Otherwise: clock_gettime(CLOCK_MONOTONIC)

So far (since Python 3.5), no one complained about build error on any platform. It looks safe in practice to expect clock_gettime() to be available.

I suggest to close this issue, and only change the code is Python fails to build on a specific platform.

By the way, glibc 2.31 release notes: "We plan to remove the obsolete function ftime, and the header <sys/timeb.h>, in a future version of glibc."
msg365794 - (view) Author: Jérôme (jerome.hamm) * Date: 2020-04-04 21:44

I think it is nice to inform the user that clock_gettime is mandatory (just like pthreads, see PR). Can be nice for someone trying to port it to a new platform.

"It's no particularly silly, is it?"
msg365800 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-04-04 22:42
Usually, what I did to use #error in the C code. Something like:

#elif defined(...)
#  error "your platform doesn't support monotonic clock"

I dislike relying on configure for that, it's too far from the actual implementation (like pymonotonic()).
msg365822 - (view) Author: Jérôme (jerome.hamm) * Date: 2020-04-05 14:36
Yes, I get your meaning, and I totally agree with it, I was wondering what was the best way to do it, stay close to the cause, which would allow to more easily go along with changes, or put it in the configure file and warn the user as soon as possible... It was kind of a flip a coin decision in the end.

For my information, is there a kind of committee or someone taking these kinds of decisions or at least expressing rules as to the spirit in which they should be made?

On the same track, how can I find why someone wrote "
/* Various compilers have only certain posix functions */
/* XXX Gosh I wish these were all moved into pyconfig.h */
" in posixmodule.c? Is it just because no-one had the opportunity to do it and it is OK for me to do it?

"Fetchez la vache"
msg412100 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2022-01-29 19:44
> For my information, is there a kind of committee or someone taking these kinds of decisions or at least expressing rules as to the spirit in which they should be made?

You can bring this up on the python-ideas mailing list if you want to pull in additional core developers into the discussion.
msg412166 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2022-01-30 17:15
I'll close this in a week if there is no response. 

(It seems to have been abandoned by the OP after a minor code review disagreement if I understand their last comment.)
Date User Action Args
2022-04-11 14:59:29adminsetgithub: 84355
2022-02-06 19:16:53iritkatrielsetstatus: pending -> closed
stage: patch review -> resolved
2022-01-30 17:15:01iritkatrielsetstatus: open -> pending

messages: + msg412166
2022-01-29 19:44:07iritkatrielsetnosy: + iritkatriel
messages: + msg412100
2020-04-05 14:39:50pmppsetnosy: + pmpp
2020-04-05 14:37:00jerome.hammsetmessages: + msg365822
2020-04-05 13:21:09python-devsetpull_requests: + pull_request18748
2020-04-04 22:42:33vstinnersetmessages: + msg365800
2020-04-04 21:44:44jerome.hammsetmessages: + msg365794
2020-04-04 21:36:29python-devsetkeywords: + patch
nosy: + python-dev

pull_requests: + pull_request18736
stage: patch review
2020-04-04 19:35:49vstinnersetmessages: + msg365775
2020-04-04 10:43:32jerome.hammsetmessages: + msg365758
2020-04-04 08:56:32jerome.hammsetmessages: + msg365751
2020-04-03 17:58:06vstinnersetnosy: + vstinner
2020-04-03 17:49:29benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg365712
2020-04-03 15:30:09jerome.hammcreate