clock_gettime
Locked
 
|
Is there any chance of clock_gettime being implemented in MinGW? MinGW64 has it but I don't like MinGW64. Source code is public domain. See link below. It would also need at least clockid_t and clock_getcpuclockid. Marchttps://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ MinGW-users mailing list [hidden email] This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:[hidden email]?subject=unsubscribe |
|
|
On 2017-05-29 00:38, DAVENPORT, MARC wrote:
> Is there any chance of clock_gettime being implemented in MinGW? MinGW64 has it but I don't like MinGW64. Source code is public domain. See link below. It would also need at least clockid_t and clock_getcpuclockid. > > https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 Hmm, their CLOCK_MONOTONIC wraps, and rather quickly too on some machines [1]; it's nothing more than a dirty hack as it's not monotonic at all. Unless I'm missing something non-obvious... Cheers, Peter [1] I've seen machines wrap the performance counter within the hour, albeit many years ago, but the non-handling of the fundamental timer wrap problem persists. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ MinGW-users mailing list [hidden email] This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:[hidden email]?subject=unsubscribe |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Apologies for the delayed reply ... this seems to have slipped under my radar. > On 2017-05-29 00:38, DAVENPORT, MARC wrote: >> Is there any chance of clock_gettime being implemented in MinGW? I think I've said this before; (if not, I've certainly alluded to it): your best chance of getting such requests accepted is to file them as "Feature Requests", at https://sourceforge.net/p/mingw/bugs/new/, and then invite other users to vote for them, (by posting a notification here). >> MinGW64 has it but I don't like MinGW64. Source code is public >> domain. See link below. It would also need at least clockid_t ... It would, if the API is to be supported; prior to POSIX.1-2008, the entire API was optional, and even now all but CLOCK_REALTIME appear to remain so. In any case, right now, I would be able to offer tentative implementations for CLOCK_REALTIME and CLOCK_MONOTONIC, but... >> and clock_getcpuclockid. ...this may NOT be required, because a) it is required only when the CLOCK_PROCESS_CPUTIME_ID option (_POSIX_CPUTIME feature) is supported, and b) I do not currently have even a tentative implementation for it. Notwithstanding the lack of enthusiasm exhibited here, if you'd care to raise the appropriate "Feature Request" ticket, I'll attach my tentative implementation for consideration. On 29/05/17 08:30, Peter Rosin replied: >> https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winpthreads/src/clock.c#L109 > > Hmm, their CLOCK_MONOTONIC wraps, and rather quickly too on some > machines [1]; it's nothing more than a dirty hack as it's not > monotonic at all. > > Unless I'm missing something non-obvious... I don't know. I haven't looked at their implementation, (nor will I), so I cannot comment. My tentative implementation does not appear to exhibit any such trait: indeed, with a reported update frequency of 3,579,545 ticks per second, (on my GNU/Linux hosted WinXP VM), and a 64-bit limit of 2^63 ticks before wrap-around, it should outlive any likely uptime cycle of the host, (or any of us, for that matter)! - -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJZXkz0AAoJEMCtNsY0flo/PEIQAJi697fRiENNJ+Iw/7MAEPC9 2SzpUFAEXJubB34QENQRDuKN5NWKRFXzvB019IEYkIDL2BxFGBkFTyyDDLP9M+mr fakRQmABPFD7eLFAvZu4tzffgA4tChkNYFCUDey34XDQaw41UKWJoOFkt7JuE5dc 66ICJW+g9KiuHa+h7if3gW9MH+lxMEO6ZV9u5GYlk7ET8tm3llwAVjKHsSq/jvmF usxVATkEKD5Tv36xDUc78mTG/LpdUEXQBgEVslXNKzaRYpZX9XdG8okQtk4eHT4O YyS0HslqLQcfN79nvYbBW/BQq6k+9ZtyqSlkQbsaS8aW5V/ccPFt9a3ce6Gadelx 5rZv93gUp7yzUR8qjf7RalbLhp/yPnWD3dIPELCxZwUqmqa8uHP0rCI9REKkkfaL wkAvih1Jcrnsp1mX0c4aUmURN1o5oK+N8ZTSPqqn29KuztKMdB0chpWKRCItJf7x F2bgFCtpwdy4a50QbkgrLzpdnh5m3wIKP6yr2dlWD2bccaRBqE7OxnsSce9IZoGQ fJ8AmzRjRQ+5n07TrlP/u8VlMgLDGF7yvbx21miHwVwRqHrfyFz3xGu5QMUBAlQg dou2FjgQW5Rwkoxury5WouSmdneaUC7j7jChkzopuW+Nna2AfFd/HyvSP4a4qJot ei/mj2HS4SZnOrDZ9Y8l =K0+V -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ MinGW-users mailing list [hidden email] This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users Also: mailto:[hidden email]?subject=unsubscribe |
«
Return to MinGW - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |