Missing clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel)

It could be a mere matter of extending the mapped-time interface: add it to mapped_time_value_t in gnumach, handle it in gnumach/kern/mach_clock.c, and make clock_gettime use it.

BTW, also make gettimeofday() use it, since it's way more efficient and some applications assume that it is.

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