From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- .../clock_gettime.mdwn | 348 --------------------- 1 file changed, 348 deletions(-) delete mode 100644 service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn b/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn deleted file mode 100644 index 407a104c..00000000 --- a/service_solahart_jakarta_selatan__082122541663/clock_gettime.mdwn +++ /dev/null @@ -1,348 +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. - -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 - - yeah, i had a draft of improved idea for also handling - nanoseconds - pinotree: Ah, nice, I thought about nanoseconds as well. - pinotree, youpi: This memory page is all-zero by default, - right? - 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)? - In case that isn't your plan anyway. - it's all-zero, yes - Or, we say if a field is != 0 it is valid. - making the last int a version code limits the size to one page - I was thinking a field != 0 being valid is simpler - but it's probably a problem too - in that glibc usually caches whether interfaces are supported - Wrap-around? - for some clocks, it may be valid that the value is 0 - wrap-around is another issue too - Well, then we can do the version-field thing, but put it right - after the current time field (address 8, I think)? - yes - it's a bit ugly, but it's hidden behind the structure - It's not too bad, I think. - yes - 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]]. - - braunr: would you send for review (and inclusion) your - time_data_t addition? - this way we could add nanosecs-based utime rpc (and then their - implementation in libc) - pinotree: it's part of the hurd branch - do you want it sent separately ? - yeah - ok - let me get it right first :) - sure :) - - -## IRC, freenode, #hurd, 2013-02-12 - - pinotree: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a - uh nice - will need two small inline functions to convert time_data_t <-> - timespec, but that's it - hm right - i could have thought about it - but i'll leave it for another patch :p - oh sure, no hurry - - -## IRC, freenode, #hurd, 2013-02-19 - - braunr: about time_data_t, I get it's needed that it be an array - so it can be passed by reference, not by value? - by address, yes - that's the difference between array and struct - - -## IRC, freenode, #hurd, 2013-02-25 - - braunr: why did you want to see time_data passed as pointer, not as - struct? - to microoptimize - the struct is 2 64-bit integers - well, we already pass structs along in a few cases, - e.g. io_statbuf_t, rusage_t, etc. - be it written t[0].sec or t->sec, it seems odd - copying 2 64bit integers is not much compared to the potential for - bugs here - bugs ? - yes, as in trying to access t[1], passing a wrong pointer, etc. - or the reader frowning on "why is this case different than the - others?" - well, i'm already usually frowning when i see what mig does .. - right - on the plus side, it's only the client side, i.e. mostly glibc, - which sees the t[0] - and the practice established by my patch is to convert to struct - timespec as soon as possible - the direct use of this type is therefore limited - could we define time_data_t as a struct time_data * instead of - struct time_data[1] ? - (in the.h) - that would make more sense to define a struct time_data, and pass a - pointer to it - i'm not sure - the mach server writing guide was very clear about array implying - a C array too - and i remember having compilation problems before doing that - but i don't remember their nature exactly - I'm not sure to understand what you said about converting to struct - timespec - what makes it not possible now? - and what is the relation with being an array or a pointer? - 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) - about the rest, i'm not sure, i'd have to try again - mig just assumes it's an array - and why not just using struct timespec? - (for the mig type too) - my brain can't correctly compute variable sized types in mig - definition files - i wanted something that would remain correct for the 64-bit port - -[[64-bit_port]], [[mig_portable_rpc_declarations]]. - - ah, you mean because tv_nsec is a long, which will not be the same - type? - and tv_sec being a time_t (thus a long too) - but we have the same issue e.g. for the rusage structure, don't we? - yes - so we'll have to fix things for that too anyway - sure - making a special case will not necessarily help - but it doesn't mean new interfaces have to be buggy too - well, using the proper type in the server itself is nicer - instead of having to convert - yes - i'm not exactly sure where to declare struct timespec then - should it be declared in hurd_types.h, and simply reused by the - libc headers ? - ? AIUI, it's the converse, hurd_types.h uses the struct timespec - from libc headers, and defines timespec_t - ok - timespec_t being the internal type whose definition gets done right - for mig to do the right thing - yes - i see - so, you'd like a struct of integer_t instead of an array of - signed64 - for our current 32bit userland yes - do you want to make the changes yourself or should i add a new - branch ? - and we'll make that a 64bit struct when we have a64bit userland - - -# IRC, freenode, #hurd, 2013-04-06 - - 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? - 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 - - do we have CLOCK_MONOTONIC ? - teythoon: i think we do but it's actually a simple offset from - CLOCK_REALTIME .. :) - ah never mind, I do hate this posix time interface anyways - really ? - i think librt is decent - - -# Candidate for [[vDSO]] code? - - -# IRC, freenode, #hurd, 2014-02-23 - - GLib (gthread-posix.c): Unexpected error from C library during - 'pthread_condattr_setclock': Invalid argument. Aborting. - uh oh... - time to go digging in glibc i guess... - what are you trying to run ? - glib - with what ? - just running glib's test suite under jhbuild - i maintain glib and i made some changes recently -- i wanted to - make sure they didn't break the hurd - and it seems they have ;/ - well - the hurd doesn't completely comply with posix 2008 - 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 - so i just added an assert -- and indeed it fails on hurd - our glibc lies about supporting timers - good thinking - we don't support the monotonic clock - clock_gettime(CLOCK_MONOTONIC) seems to work - and you should know that, even if clock selection and timers are - available (which posix 2008 requires), it's still optional - no, glibc lies - !! - our "support" is a mere hack shifting CLOCK_REALTIME - it should at least lie consistently :) - we need to implement CLOCK_MONOTONIC properly - ya... that would be very nice indeed - not that hard either - i agree! - we just have to do it right - fwiw, i plan to keep this assert in glib - yes, it's good - is there anywhere i can file a bug to give you guys some advance - warning? - i don't think it's needed - we know the problem - k -- consider yourself warned, then :) - and it's been a bigger concern recently - awesome. glad i don't have to do anything :) - if it's not already done, i suggest you check for the - CLOCK_MONOTONIC option - fwiw, i'm trying to get a regular debian/gnu/hurd build of - glib/gtk/etc setup - regular ? - ya... out of git master on a daily basis - from sources ? - oh nice - we recently set this up for freebsd as well - few maintainers take the pain :) - our non-linux 'problem discovery' is a bit crap before now :/ - i guess that's pretty normal - i don't consider it the responsibility of the maintainers to test - every possible platform - glib is a bit unique -- portability is our business - taking our patches into consideration is what we ask most - right - and the "please take the patches" thing is something we want to - stop doing - why ? - mostly because we often look at a patch that someone sent a few - years ago and say "do we even still need this?" - and have no way to know - uh - you would not believe how many patches like this we've - accumulated... - but if we send it now ? :) - braunr: new policy is roughly this: - https://wiki.gnome.org/Projects/GLib/SupportedPlatforms - ie: fixes for issues that are general portability improvements and - POSIX compliance are welcome... - patches that introduce platform-specific #ifdef sections are - rejected unless we have a regular builder to test that code - i see - again, regarding portability, don't consider CLOCK_MONOTONIC to be - readily available, check for it - an #error would be enough but it has to be checked - it basically comes down to: we don't want to have code in our - version control that we have no possible way of testing - yes - braunr: we do check for it - ok - we assert() if clock_gettime(CLOCK_MONOTONIC) fails - no i mean - as POSIX said it should if CLOCK_MONOTONIC is not supported - if you lie to us.... well, not much we can do - POSIX_MONOTONIC_CLOCK - _POSIX_MONOTONIC_CLOCK - this is actually defined to 0 on most platforms... - 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 - really ? - yes - we used to rely on this and got a bug that we were doing it wrong - :) - and indeed, even on linux, both with glibc and uclibc: - /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK - 0 - /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK - 0 - ok it's described in 2.1.6 Options - so your check is appropriate - so does clock_gettime(MONOTONIC) on debian/hurd get me realtime? - either that, or a value shifted from it - if so, i'll just hack out the condattr_setclock() check and proceed - trying to build past glib... - * desrt checks - as it is, even the build of glib fails since we use some tools - linked against ourselves during the build process... - 1393124084790000 1393124084790000 - those look the same.... - heh - i also notice that your clocks are not very high precision :) - that's right - HZ = 100, i guess - yes - fair enough - our mainloop doesn't support better-than-millisecond accuracy yet - anyway :) - (although it will soon...) - nice - - -## IRC, freenode, #hurd, 2014-03-05 - - 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 - desrt: ok -- cgit v1.2.3