diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn')
| -rw-r--r-- | service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn | 348 |
1 files changed, 348 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn b/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn new file mode 100644 index 00000000..407a104c --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn @@ -0,0 +1,348 @@ +[[!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 + + +## 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 |