[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 1/1 Web] Open issues: Update clock_gettime page
|
From: |
Zhaoming Luo |
|
Subject: |
[PATCH 1/1 Web] Open issues: Update clock_gettime page |
|
Date: |
Tue, 14 Jan 2025 09:50:01 +0800 |
The clock_gettime(CLOCK_MONOTONIC) is implemented. See
https://sourceware.org/git?p=glibc.git;a=commit;h=3782ffaf3e6c2a071df029b96712e596b5229838
so this page is out of date.
Rename the page to nanosecond-precision_clock, and remove the
information about clock_gettime(CLOCK_MONOTONIC).
---
open_issues/clock_gettime.mdwn | 345 --------------------
open_issues/nanosecond-precision_clock.mdwn | 56 ++++
2 files changed, 56 insertions(+), 345 deletions(-)
delete mode 100644 open_issues/clock_gettime.mdwn
create mode 100644 open_issues/nanosecond-precision_clock.mdwn
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
deleted file mode 100644
index 6f2ad6fd..00000000
--- a/open_issues/clock_gettime.mdwn
+++ /dev/null
@@ -1,345 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation,
-Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!meta title="clock_gettime"]]
-
-[[!tag open_issue_glibc open_issue_gnumach]]
-
-Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
-
-It could be a mere matter of extending the
-[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]:
-add it to
-`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
-make `clock_gettime` use it.
-
-What about adding a nanosecond-precision clock, too? --[[tschwinge]]
-
-
-# IRC, freenode, #hurd, 2011-08-26
-
- < pinotree> youpi: thing is: apparently i found a simple way to have a
- monotonic clock as mmap-able device inside gnumach
- < pinotree> currently, in kern/mach_clock.c there's a variable 'time',
- which gets increased on clock interrupt, and optionally modified by
- host_set_time
- < pinotree> ()
- < pinotree> if i add a new variable next to it, only increasing it on
- interrupt but not modifying it at all otherwise, would that give me a
- monotonic clock?
- < pinotree> at least on sme basic tests i did, it seems it could work that
- way
- < youpi> yes, it should work
- < braunr> sure
- < youpi> and that's the way I was considering implementing it
-
-
-# IRC, freenode, #hurd, 2011-09-06
-
- <pinotree> yeah, i had a draft of improved idea for also handling
- nanoseconds
- <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well.
- <tschwinge> pinotree, youpi: This memory page is all-zero by default,
- right?
- <tschwinge> Can't we then say that its last int is a version code, and if
- it is 0 (as it is now), we only have the normal mapped time field, if it
- is 1, we also have the monotonic cliock and ns precision on address 8 and
- 16 (or whatever)?
- <tschwinge> In case that isn't your plan anyway.
- <youpi> it's all-zero, yes
- <tschwinge> Or, we say if a field is != 0 it is valid.
- <youpi> making the last int a version code limits the size to one page
- <youpi> I was thinking a field != 0 being valid is simpler
- <youpi> but it's probably a problem too
- <youpi> in that glibc usually caches whether interfaces are supported
- <tschwinge> Wrap-around?
- <youpi> for some clocks, it may be valid that the value is 0
- <youpi> wrap-around is another issue too
- <tschwinge> Well, then we can do the version-field thing, but put it right
- after the current time field (address 8, I think)?
- <youpi> yes
- <youpi> it's a bit ugly, but it's hidden behind the structure
- <tschwinge> It's not too bad, I think.
- <youpi> yes
- <tschwinge> And it will forever be a witness of the evolving of this
- map_time interface. :-)
-
-
-# IRC, freenode, #hurd, 2013-02-11
-
-In context of [[select]].
-
- <pinotree> braunr: would you send for review (and inclusion) your
- time_data_t addition?
- <pinotree> this way we could add nanosecs-based utime rpc (and then their
- implementation in libc)
- <braunr> pinotree: it's part of the hurd branch
- <braunr> do you want it sent separately ?
- <pinotree> yeah
- <braunr> ok
- <braunr> let me get it right first :)
- <pinotree> sure :)
-
-
-## IRC, freenode, #hurd, 2013-02-12
-
- <braunr> pinotree:
-
https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a
- <pinotree> uh nice
- <pinotree> will need two small inline functions to convert time_data_t <->
- timespec, but that's it
- <braunr> hm right
- <braunr> i could have thought about it
- <braunr> but i'll leave it for another patch :p
- <pinotree> oh sure, no hurry
-
-
-## IRC, freenode, #hurd, 2013-02-19
-
- <youpi> braunr: about time_data_t, I get it's needed that it be an array
- <youpi> so it can be passed by reference, not by value?
- <braunr> by address, yes
- <braunr> that's the difference between array and struct
-
-
-## IRC, freenode, #hurd, 2013-02-25
-
- <youpi> braunr: why did you want to see time_data passed as pointer, not as
- struct?
- <braunr> to microoptimize
- <braunr> the struct is 2 64-bit integers
- <youpi> well, we already pass structs along in a few cases,
- e.g. io_statbuf_t, rusage_t, etc.
- <youpi> be it written t[0].sec or t->sec, it seems odd
- <youpi> copying 2 64bit integers is not much compared to the potential for
- bugs here
- <braunr> bugs ?
- <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc.
- <youpi> or the reader frowning on "why is this case different than the
- others?"
- <braunr> well, i'm already usually frowning when i see what mig does ..
- <youpi> right
- <youpi> on the plus side, it's only the client side, i.e. mostly glibc,
- which sees the t[0]
- <braunr> and the practice established by my patch is to convert to struct
- timespec as soon as possible
- <braunr> the direct use of this type is therefore limited
- <youpi> could we define time_data_t as a struct time_data * instead of
- struct time_data[1] ?
- <youpi> (in the.h)
- <youpi> that would make more sense to define a struct time_data, and pass a
- pointer to it
- <braunr> i'm not sure
- <braunr> the mach server writing guide was very clear about array implying
- a C array too
- <braunr> and i remember having compilation problems before doing that
- <braunr> but i don't remember their nature exactly
- <youpi> I'm not sure to understand what you said about converting to struct
- timespec
- <youpi> what makes it not possible now?
- <youpi> and what is the relation with being an array or a pointer?
- <braunr> concerning struct timespec, what i mean is that the functions
- called by the mig stub code directly convert time_data_t to a struct
- timespec (which is the real type used throughout the hurd code)
- <braunr> about the rest, i'm not sure, i'd have to try again
- <braunr> mig just assumes it's an array
- <youpi> and why not just using struct timespec?
- <youpi> (for the mig type too)
- <braunr> my brain can't correctly compute variable sized types in mig
- definition files
- <braunr> i wanted something that would remain correct for the 64-bit port
-
-[[64-bit_port]], [[mig_portable_rpc_declarations]].
-
- <youpi> ah, you mean because tv_nsec is a long, which will not be the same
- type?
- <braunr> and tv_sec being a time_t (thus a long too)
- <youpi> but we have the same issue e.g. for the rusage structure, don't we?
- <braunr> yes
- <youpi> so we'll have to fix things for that too anyway
- <braunr> sure
- <youpi> making a special case will not necessarily help
- <braunr> but it doesn't mean new interfaces have to be buggy too
- <youpi> well, using the proper type in the server itself is nicer
- <youpi> instead of having to convert
- <braunr> yes
- <braunr> i'm not exactly sure where to declare struct timespec then
- <braunr> should it be declared in hurd_types.h, and simply reused by the
- libc headers ?
- <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec
- from libc headers, and defines timespec_t
- <braunr> ok
- <youpi> timespec_t being the internal type whose definition gets done right
- for mig to do the right thing
- <braunr> yes
- <braunr> i see
- <braunr> so, you'd like a struct of integer_t instead of an array of
- signed64
- <youpi> for our current 32bit userland yes
- <braunr> do you want to make the changes yourself or should i add a new
- branch ?
- <youpi> and we'll make that a 64bit struct when we have a64bit userland
-
-
-# IRC, freenode, #hurd, 2013-04-06
-
- <tschwinge> pinotree: You had once been working on adding nsec-procision
- timestamps to GNU Mach's maptime interface (or what the name is). Is
- that blocked on something or just waiting to be continued?
- <pinotree> blocked on me needing to learn more the proper way to do
- "atomic" update of the struct with time :)
-
-
-# IRC, freenode, #hurd, 2013-09-04
-
- <teythoon> do we have CLOCK_MONOTONIC ?
- <braunr> teythoon: i think we do but it's actually a simple offset from
- CLOCK_REALTIME .. :)
- <teythoon> ah never mind, I do hate this posix time interface anyways
- <braunr> really ?
- <braunr> i think librt is decent
-
-
-# Candidate for [[vDSO]] code?
-
-
-# IRC, freenode, #hurd, 2014-02-23
-
- <desrt> GLib (gthread-posix.c): Unexpected error from C library during
- 'pthread_condattr_setclock': Invalid argument. Aborting.
- <desrt> uh oh...
- <desrt> time to go digging in glibc i guess...
- <braunr> what are you trying to run ?
- <desrt> glib
- <braunr> with what ?
- <desrt> just running glib's test suite under jhbuild
- <desrt> i maintain glib and i made some changes recently -- i wanted to
- make sure they didn't break the hurd
- <desrt> and it seems they have ;/
- <braunr> well
- <braunr> the hurd doesn't completely comply with posix 2008
- <desrt> long story short: we've keyed our timed waits on condition
- variables to the monotonic clock for a long time now, but we never tested
- that it actually worked
- <desrt> so i just added an assert -- and indeed it fails on hurd
- <braunr> our glibc lies about supporting timers
- <braunr> good thinking
- <braunr> we don't support the monotonic clock
- <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work
- <braunr> and you should know that, even if clock selection and timers are
- available (which posix 2008 requires), it's still optional
- <braunr> no, glibc lies
- <desrt> !!
- <braunr> our "support" is a mere hack shifting CLOCK_REALTIME
- <desrt> it should at least lie consistently :)
- <braunr> we need to implement CLOCK_MONOTONIC properly
- <desrt> ya... that would be very nice indeed
- <braunr> not that hard either
- <desrt> i agree!
- <braunr> we just have to do it right
- <desrt> fwiw, i plan to keep this assert in glib
- <braunr> yes, it's good
- <desrt> is there anywhere i can file a bug to give you guys some advance
- warning?
- <braunr> i don't think it's needed
- <braunr> we know the problem
- <desrt> k -- consider yourself warned, then :)
- <braunr> and it's been a bigger concern recently
- <desrt> awesome. glad i don't have to do anything :)
- <braunr> if it's not already done, i suggest you check for the
- CLOCK_MONOTONIC option
- <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of
- glib/gtk/etc setup
- <braunr> regular ?
- <desrt> ya... out of git master on a daily basis
- <braunr> from sources ?
- <braunr> oh nice
- <desrt> we recently set this up for freebsd as well
- <braunr> few maintainers take the pain :)
- <desrt> our non-linux 'problem discovery' is a bit crap before now :/
- <braunr> i guess that's pretty normal
- <braunr> i don't consider it the responsibility of the maintainers to test
- every possible platform
- <desrt> glib is a bit unique -- portability is our business
- <braunr> taking our patches into consideration is what we ask most
- <braunr> right
- <desrt> and the "please take the patches" thing is something we want to
- stop doing
- <braunr> why ?
- <desrt> mostly because we often look at a patch that someone sent a few
- years ago and say "do we even still need this?"
- <desrt> and have no way to know
- <braunr> uh
- <desrt> you would not believe how many patches like this we've
- accumulated...
- <braunr> but if we send it now ? :)
- <desrt> braunr: new policy is roughly this:
- https://wiki.gnome.org/Projects/GLib/SupportedPlatforms
- <desrt> ie: fixes for issues that are general portability improvements and
- POSIX compliance are welcome...
- <desrt> patches that introduce platform-specific #ifdef sections are
- rejected unless we have a regular builder to test that code
- <braunr> i see
- <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to be
- readily available, check for it
- <braunr> an #error would be enough but it has to be checked
- <desrt> it basically comes down to: we don't want to have code in our
- version control that we have no possible way of testing
- <braunr> yes
- <desrt> braunr: we do check for it
- <braunr> ok
- <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails
- <braunr> no i mean
- <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported
- <desrt> if you lie to us.... well, not much we can do
- <braunr> POSIX_MONOTONIC_CLOCK
- <braunr> _POSIX_MONOTONIC_CLOCK
- <desrt> this is actually defined to 0 on most platforms...
- <desrt> which does not mean that it's unsupported -- it means that the
- runtime must be ready to deal with it not actually existing at runtime
- <braunr> really ?
- <desrt> yes
- <desrt> we used to rely on this and got a bug that we were doing it wrong
- :)
- <desrt> and indeed, even on linux, both with glibc and uclibc:
- <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
- 0
- <desrt> /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
- 0
- <braunr> ok it's described in 2.1.6 Options
- <braunr> so your check is appropriate
- <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime?
- <braunr> either that, or a value shifted from it
- <desrt> if so, i'll just hack out the condattr_setclock() check and proceed
- trying to build past glib...
- * desrt checks
- <desrt> as it is, even the build of glib fails since we use some tools
- linked against ourselves during the build process...
- <desrt> 1393124084790000 1393124084790000
- <desrt> those look the same....
- <braunr> heh
- <desrt> i also notice that your clocks are not very high precision :)
- <braunr> that's right
- <desrt> HZ = 100, i guess
- <braunr> yes
- <desrt> fair enough
- <desrt> our mainloop doesn't support better-than-millisecond accuracy yet
- anyway :)
- <desrt> (although it will soon...)
- <braunr> nice
-
-
-## IRC, freenode, #hurd, 2014-03-05
-
- <desrt> braunr: bit of a warning: i released the glib that depends on
- working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it
- will be landing in debian within the next days
- <braunr> desrt: ok
diff --git a/open_issues/nanosecond-precision_clock.mdwn
b/open_issues/nanosecond-precision_clock.mdwn
new file mode 100644
index 00000000..e71e1558
--- /dev/null
+++ b/open_issues/nanosecond-precision_clock.mdwn
@@ -0,0 +1,56 @@
+[[!meta copyright="Copyright © 2011, 2013, 2014, 2025 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="a nanosecond-precision clock"]]
+
+[[!tag open_issue_glibc open_issue_gnumach]]
+
+What about adding a nanosecond-precision clock, too? --[[tschwinge]]
+
+# IRC, freenode, #hurd, 2011-09-06
+
+ <pinotree> yeah, i had a draft of improved idea for also handling
+ nanoseconds
+ <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well.
+ <tschwinge> pinotree, youpi: This memory page is all-zero by default,
+ right?
+ <tschwinge> Can't we then say that its last int is a version code, and if
+ it is 0 (as it is now), we only have the normal mapped time field, if it
+ is 1, we also have the monotonic cliock and ns precision on address 8 and
+ 16 (or whatever)?
+ <tschwinge> In case that isn't your plan anyway.
+ <youpi> it's all-zero, yes
+ <tschwinge> Or, we say if a field is != 0 it is valid.
+ <youpi> making the last int a version code limits the size to one page
+ <youpi> I was thinking a field != 0 being valid is simpler
+ <youpi> but it's probably a problem too
+ <youpi> in that glibc usually caches whether interfaces are supported
+ <tschwinge> Wrap-around?
+ <youpi> for some clocks, it may be valid that the value is 0
+ <youpi> wrap-around is another issue too
+ <tschwinge> Well, then we can do the version-field thing, but put it right
+ after the current time field (address 8, I think)?
+ <youpi> yes
+ <youpi> it's a bit ugly, but it's hidden behind the structure
+ <tschwinge> It's not too bad, I think.
+ <youpi> yes
+ <tschwinge> And it will forever be a witness of the evolving of this
+ map_time interface. :-)
+
+# IRC, freenode, #hurd, 2013-04-06
+
+ <tschwinge> pinotree: You had once been working on adding nsec-procision
+ timestamps to GNU Mach's maptime interface (or what the name is). Is
+ that blocked on something or just waiting to be continued?
+ <pinotree> blocked on me needing to learn more the proper way to do
+ "atomic" update of the struct with time :)
+
+# Candidate for [[vDSO]] code?
--
2.47.1