summaryrefslogtreecommitdiff
path: root/open_issues/clock_gettime.mdwn
blob: baa21bbbe27a45378fcbe247ec5c37aeceb981ae (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
[[!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.

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:
      http://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