clock(3) non-functional?

Hi, Looking at libsamplerate test problems, I found that clock(3) used there is not reliable. Strange results are obtained on too Linux with a simple test program. Using clock_gettime(2) instead on both Linux and Hurd works perfectly. The Linux man page for clock(3) says that it is implemented on

Processed: reassign 752237 to hurd

Processing commands for cont...@bugs.debian.org: > reassign 752237 hurd Bug #752237 [libc0.3] libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd Bug reassigned from package 'libc0.3' to 'hurd'. No longer marked as found in versions eglibc/2.19-3. Ignoring request to alter fix

Re: clock(3) non-functional?

Hello, Svante Signell, le Sun 29 Jun 2014 16:35:42 +0200, a écrit : > Looking at libsamplerate test problems, I found that clock(3) used > there is not reliable. Strange results are obtained on too Linux with a > simple test program. What do you mean by "strange"? The output I get $ ./test start

Re: clock(3) non-functional?

On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > Hello, > > The following simple program gives unreliable results both on Linux and > > especially Hurd: > > Again, what do you mean by "unreliable"? What did you expect? I'd expected an elapsed time of 3 seconds with a sleep(3) in betw

Re: clock(3) non-functional?

Svante Signell, le Sun 29 Jun 2014 23:11:14 +0200, a écrit : > On Sun, 2014-06-29 at 22:56 +0200, Samuel Thibault wrote: > > Hello, > > > > The following simple program gives unreliable results both on Linux and > > > especially Hurd: > > > > Again, what do you mean by "unreliable"? What did you