On 28/07/17 10:13, Richard Braun wrote: > On Fri, Jul 28, 2017 at 11:10:29AM +0200, Richard Braun wrote: >> On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: >>> On 28/07/17 09:05, Richard Braun wrote: >>>> On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: >>>>> While debugging a timing problem with FFmpeg on Hurd, I noticed that the >>>>> "clock" function has a far lower precision on Hurd than it does on >>>>> Linux, even though CLOCKS_PER_SEC is 1000000 on both. Why is this? >>>>> >>>>> I also found this patch to libc which may be responsible: >>>>> hurd-i386/unsubmitted-clock_t_centiseconds.diff >>>>> >>>>> I'm not entirely sure why patching libc is appropriate to fix the >>>>> claimed issues. >>>> >>>> The patch has nothing to do with precision. The kernel simply doesn't >>>> have any high resolution timing system, whereas Linux does. >>> >>> In that case, clock should be returning multiples of whatever precision >>> is supported by the kernel so that CLOCKS_PER_SEC is still correct. >> >> That macro is required by XSI to have this value, as described by POSIX [1]. > > I replied too quickly. I don't have all the details in mind but you may > be right. Please use the bug-hurd@gnu.org mailing list to report this > issue upstream. I have a feeling it's not an upstream issue. The patch I mentioned above is only applied in Debian's glibc package. Thanks, James
Attachment:
signature.asc
Description: OpenPGP digital signature