From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- open_issues/clock_gettime.mdwn | 132 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 131 insertions(+), 1 deletion(-) (limited to 'open_issues/clock_gettime.mdwn') diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 65ab52df..baa21bbb 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] +[[!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 @@ -158,6 +159,9 @@ In context of [[select]]. 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) @@ -208,3 +212,129 @@ In context of [[select]]. # 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 -- cgit v1.2.3