* pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early @ 2018-11-25 14:01 James E. King III 2018-11-26 15:35 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: James E. King III @ 2018-11-25 14:01 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1985 bytes --] I have isolated a problem in pthread_cond_timedwait when the condattr is used to set the clock type to CLOCK_MONOTONIC. In this case even though a target time point in the future is specified, the call returns ETIMEDOUT but a subsequent call to clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not reached. $ gcc timed_wait_short.c -o timed_wait_short $ ./timed_wait_short.exe begin: 521036s 122315900n target: 521036s 172315900n end: 521036s 173293100n ok: true begin: 521036s 174872400n target: 521036s 224872400n end: 521036s 224378900n ok: false Jim@pulsar /cygdrive/c/users/jim/desktop $ ./timed_wait_short.exe begin: 521052s 95953200n target: 521052s 145953200n end: 521052s 145284000n ok: false Jim@pulsar /cygdrive/c/users/jim/desktop $ ./timed_wait_short.exe begin: 521056s 396277200n target: 521056s 446277200n end: 521056s 446664700n ok: true begin: 521056s 454535100n target: 521056s 504535100n end: 521056s 504567000n ok: true begin: 521056s 510360800n target: 521056s 560360800n end: 521056s 560555600n ok: true begin: 521056s 566604400n target: 521056s 616604400n end: 521056s 616622800n ok: true begin: 521056s 619277800n target: 521056s 669277800n end: 521056s 669646400n ok: true begin: 521056s 671907500n target: 521056s 721907500n end: 521056s 721578000n ok: false I have attached the source code. Cygwin DLL version info: DLL version: 2.11.2 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 329 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 [-- Attachment #2: timed_wait_short.c --] [-- Type: text/plain, Size: 1915 bytes --] /* * Copyright (C) 2018 James E. King III * * This test exposes a problem in cygwin's condition variable clock * handling when setclock(CLOCK_MONOTONIC) is used on the attribute. * * Although ETIMEDOUT is being returned by pthread_cond_timedwait, * a subsequent fetch of the clock shows that the time point was not * reached. */ #include <assert.h> #include <errno.h> #include <pthread.h> #include <stdio.h> #include <time.h> int main() { int ok; pthread_cond_t cv; pthread_condattr_t attr; pthread_mutex_t m; assert(!pthread_condattr_init(&attr)); pthread_condattr_setclock(&attr, CLOCK_MONOTONIC); assert(!pthread_mutex_init(&m, NULL)); assert(!pthread_cond_init(&cv, &attr)); pthread_condattr_destroy(&attr); assert(!pthread_mutex_lock(&m)); do { struct timespec ts_begin; struct timespec ts_target; struct timespec ts_end; assert(!clock_gettime(CLOCK_MONOTONIC, &ts_begin)); ts_target = ts_begin; ts_target.tv_nsec += 50000000; // add 50ms if (ts_target.tv_nsec >= 1000000000) { ++ts_target.tv_sec; ts_target.tv_nsec -= 1000000000; } assert(ETIMEDOUT == pthread_cond_timedwait(&cv, &m, &ts_target)); assert(!clock_gettime(CLOCK_MONOTONIC, &ts_end)); ok = ts_end.tv_sec > ts_target.tv_sec || (ts_end.tv_sec == ts_target.tv_sec && ts_end.tv_nsec >= ts_target.tv_nsec); printf(" begin: %10us %10un\n", ts_begin.tv_sec, ts_begin.tv_nsec); printf("target: %10us %10un\n", ts_target.tv_sec, ts_target.tv_nsec); printf(" end: %10us %10un\n", ts_end.tv_sec, ts_end.tv_nsec); printf(" ok: %s\n", ok ? "true" : "false"); } while (ok); pthread_mutex_unlock(&m); pthread_mutex_destroy(&m); pthread_cond_destroy(&cv); return !ok; } [-- Attachment #3: Type: text/plain, Size: 219 bytes --] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-25 14:01 pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early James E. King III @ 2018-11-26 15:35 ` Corinna Vinschen 2018-11-26 15:47 ` James E. King III 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-11-26 15:35 UTC (permalink / raw) To: cygwin; +Cc: James E. King III [-- Attachment #1: Type: text/plain, Size: 2349 bytes --] On Nov 25 09:01, James E. King III wrote: > I have isolated a problem in pthread_cond_timedwait when the condattr > is used to set the clock type to CLOCK_MONOTONIC. In this case even > though a target time point in the future is specified, the call > returns ETIMEDOUT but a subsequent call to > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > reached. > > $ gcc timed_wait_short.c -o timed_wait_short > $ ./timed_wait_short.exe > [...] > begin: 521056s 671907500n > target: 521056s 721907500n > end: 521056s 721578000n > ok: false > > I have attached the source code. Thanks for the testcase. The problem is this: The underlying implementation uses a Windows waitable time set to implement the timeout. In case of a CLOCK_REALTIME timer, we can use the given absolut timestamp in 100ns resolution for the timer. On the other hand, the CLOCK_MONOTONIC timer is not running in absolut time but uses the hi-res timestamps generated by QueryPerformanceCounter. The perf counter uses an arbitrary "ticks per second" unit which is converted to nsecs on the fly on the POSIX API level. However, perf counters are not waitable objects, only waitable timers are, so we have to use the perf timer values to prime a waitable timer evetually. The side effect is that we have to use relative offset under the hood as soon as the base timer is CLOCK_MONOTONIC, since there's no direct relation to the absolute system time as used by the waitable timer in absolute mode. Combine this with the inaccuracy of the Windows waitable timer and wait functions in general(*) and you know what uphill battle accuracy is in this scenario. Having said that, I don't have a *good*, reliable solution to this problem. At the moment I only have an *ugly* idea: We can always add the coarsest resolution of the wait functions (typically 15.625 ms) to the relative timeout value computed from the absolute timeout given to pthread_cond_timedwait. In my testing this is sufficient since the difference between target and actual end time is always < 15ms, in thousands of runs. Thoughts? Thanks, Corinna (*) https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-26 15:35 ` Corinna Vinschen @ 2018-11-26 15:47 ` James E. King III 2018-11-26 16:47 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: James E. King III @ 2018-11-26 15:47 UTC (permalink / raw) To: cygwin On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > > On Nov 25 09:01, James E. King III wrote: > > I have isolated a problem in pthread_cond_timedwait when the condattr > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > though a target time point in the future is specified, the call > > returns ETIMEDOUT but a subsequent call to > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > reached. > > > > $ gcc timed_wait_short.c -o timed_wait_short > > $ ./timed_wait_short.exe > > [...] > > begin: 521056s 671907500n > > target: 521056s 721907500n > > end: 521056s 721578000n > > ok: false > > > > I have attached the source code. > > Thanks for the testcase. The problem is this: > > The underlying implementation uses a Windows waitable time set to > implement the timeout. In case of a CLOCK_REALTIME timer, we can use > the given absolut timestamp in 100ns resolution for the timer. > > On the other hand, the CLOCK_MONOTONIC timer is not running in absolut > time but uses the hi-res timestamps generated by QueryPerformanceCounter. > The perf counter uses an arbitrary "ticks per second" unit which is > converted to nsecs on the fly on the POSIX API level. However, perf > counters are not waitable objects, only waitable timers are, so we have > to use the perf timer values to prime a waitable timer evetually. > > The side effect is that we have to use relative offset under the hood as > soon as the base timer is CLOCK_MONOTONIC, since there's no direct > relation to the absolute system time as used by the waitable timer in > absolute mode. > > Combine this with the inaccuracy of the Windows waitable timer and wait > functions in general(*) and you know what uphill battle accuracy is in > this scenario. > > Having said that, I don't have a *good*, reliable solution to this > problem. > > At the moment I only have an *ugly* idea: We can always add the > coarsest resolution of the wait functions (typically 15.625 ms) to the > relative timeout value computed from the absolute timeout given to > pthread_cond_timedwait. In my testing this is sufficient since the > difference between target and actual end time is always < 15ms, in > thousands of runs. > > Thoughts? > > > Thanks, > Corinna > > (*) https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > -- > Corinna Vinschen > Cygwin Maintainer Some thoughts: https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 In pthread_convert_abstime, line 2564, care is taken to adjust for rounding errors. At line 2574, the rounding is not accounted for when adjusting for a relative wait because it is a monotonic clock. Wouldn't that rounding error cause it to wait less time? - Jim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-26 15:47 ` James E. King III @ 2018-11-26 16:47 ` Corinna Vinschen 2018-11-29 10:18 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-11-26 16:47 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2244 bytes --] On Nov 26 10:47, James E. King III wrote: > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > <corinna-cygwin@cygwin.com> wrote: > > > > On Nov 25 09:01, James E. King III wrote: > > > I have isolated a problem in pthread_cond_timedwait when the condattr > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > > though a target time point in the future is specified, the call > > > returns ETIMEDOUT but a subsequent call to > > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > > reached. > > > > > > $ gcc timed_wait_short.c -o timed_wait_short > > > $ ./timed_wait_short.exe > > > [...] > > > begin: 521056s 671907500n > > > target: 521056s 721907500n > > > end: 521056s 721578000n > > > ok: false > > > > > > I have attached the source code. > > > > Thanks for the testcase. The problem is this: > > [...] > > At the moment I only have an *ugly* idea: We can always add the > > coarsest resolution of the wait functions (typically 15.625 ms) to the > > relative timeout value computed from the absolute timeout given to > > pthread_cond_timedwait. In my testing this is sufficient since the > > difference between target and actual end time is always < 15ms, in > > thousands of runs. > > > > Thoughts? > > > > > > Thanks, > > Corinna > > > > (*) https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > > > -- > > Corinna Vinschen > > Cygwin Maintainer > > Some thoughts: > > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 > > In pthread_convert_abstime, line 2564, care is taken to adjust for > rounding errors. > At line 2574, the rounding is not accounted for when adjusting for a > relative wait because it is a monotonic clock. > Wouldn't that rounding error cause it to wait less time? Au contraire: - The end time you're waiting for is rounded *up*. - The current time is rounded *down* - So end time - current time is always bigger than required on the 100ns level. Make sense? Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-26 16:47 ` Corinna Vinschen @ 2018-11-29 10:18 ` Corinna Vinschen 2018-11-29 22:39 ` James E. King III 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-11-29 10:18 UTC (permalink / raw) To: cygwin; +Cc: James E. King III [-- Attachment #1: Type: text/plain, Size: 2534 bytes --] On Nov 26 17:46, Corinna Vinschen wrote: > On Nov 26 10:47, James E. King III wrote: > > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > > <corinna-cygwin@cygwin.com> wrote: > > > > > > On Nov 25 09:01, James E. King III wrote: > > > > I have isolated a problem in pthread_cond_timedwait when the condattr > > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > > > though a target time point in the future is specified, the call > > > > returns ETIMEDOUT but a subsequent call to > > > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > > > reached. > > > > > > > > $ gcc timed_wait_short.c -o timed_wait_short > > > > $ ./timed_wait_short.exe > > > > [...] > > > > begin: 521056s 671907500n > > > > target: 521056s 721907500n > > > > end: 521056s 721578000n > > > > ok: false > > > > > > > > I have attached the source code. > > > > > > Thanks for the testcase. The problem is this: > > > [...] > > > At the moment I only have an *ugly* idea: We can always add the > > > coarsest resolution of the wait functions (typically 15.625 ms) to the > > > relative timeout value computed from the absolute timeout given to > > > pthread_cond_timedwait. In my testing this is sufficient since the > > > difference between target and actual end time is always < 15ms, in > > > thousands of runs. > > > > > > Thoughts? > > > > > > > > > Thanks, > > > Corinna > > > > > > (*) https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > > > > > -- > > > Corinna Vinschen > > > Cygwin Maintainer > > > > Some thoughts: > > > > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 > > > > In pthread_convert_abstime, line 2564, care is taken to adjust for > > rounding errors. > > At line 2574, the rounding is not accounted for when adjusting for a > > relative wait because it is a monotonic clock. > > Wouldn't that rounding error cause it to wait less time? > > Au contraire: > > - The end time you're waiting for is rounded *up*. > - The current time is rounded *down* > - So end time - current time is always bigger than required > on the 100ns level. > > Make sense? I created a patch and uploaded new developer snapshots to https://cygwin.com/snapshots/ Please give them a try. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-29 10:18 ` Corinna Vinschen @ 2018-11-29 22:39 ` James E. King III 2018-11-30 12:14 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: James E. King III @ 2018-11-29 22:39 UTC (permalink / raw) To: cygwin On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > > On Nov 26 17:46, Corinna Vinschen wrote: > > On Nov 26 10:47, James E. King III wrote: > > > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > > > <corinna-cygwin@cygwin.com> wrote: > > > > > > > > On Nov 25 09:01, James E. King III wrote: > > > > > I have isolated a problem in pthread_cond_timedwait when the condattr > > > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > > > > though a target time point in the future is specified, the call > > > > > returns ETIMEDOUT but a subsequent call to > > > > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > > > > reached. > > > > > > > > > > $ gcc timed_wait_short.c -o timed_wait_short > > > > > $ ./timed_wait_short.exe > > > > > [...] > > > > > begin: 521056s 671907500n > > > > > target: 521056s 721907500n > > > > > end: 521056s 721578000n > > > > > ok: false > > > > > > > > > > I have attached the source code. > > > > > > > > Thanks for the testcase. The problem is this: > > > > [...] > > > > At the moment I only have an *ugly* idea: We can always add the > > > > coarsest resolution of the wait functions (typically 15.625 ms) to the > > > > relative timeout value computed from the absolute timeout given to > > > > pthread_cond_timedwait. In my testing this is sufficient since the > > > > difference between target and actual end time is always < 15ms, in > > > > thousands of runs. > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > Corinna > > > > > > > > (*) https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > > > > > > > -- > > > > Corinna Vinschen > > > > Cygwin Maintainer > > > > > > Some thoughts: > > > > > > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 > > > > > > In pthread_convert_abstime, line 2564, care is taken to adjust for > > > rounding errors. > > > At line 2574, the rounding is not accounted for when adjusting for a > > > relative wait because it is a monotonic clock. > > > Wouldn't that rounding error cause it to wait less time? > > > > Au contraire: > > > > - The end time you're waiting for is rounded *up*. > > - The current time is rounded *down* > > - So end time - current time is always bigger than required > > on the 100ns level. > > > > Make sense? > > I created a patch and uploaded new developer snapshots to > https://cygwin.com/snapshots/ Please give them a try. > > > Thanks, > Corinna > This fixed the issue for me. What's the best way to detect cygwin with this support? I see something around "has_precise_interrupt_time". I suppose that would be it? I need to make some changes in Boost.Thread to accomodate it. Thanks, Jim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-29 22:39 ` James E. King III @ 2018-11-30 12:14 ` Corinna Vinschen 2018-11-30 12:44 ` James E. King III 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-11-30 12:14 UTC (permalink / raw) To: cygwin; +Cc: James E. King III [-- Attachment #1: Type: text/plain, Size: 571 bytes --] On Nov 29 17:38, James E. King III wrote: > On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen > > I created a patch and uploaded new developer snapshots to > > https://cygwin.com/snapshots/ Please give them a try. > > This fixed the issue for me. What's the best way to detect cygwin > with this support? This will show up in version 2.12.0(*) so checking the release field from uname(2) should do the trick. Thanks for testing, Corinna (*) Not sure yet if the release will still occur in 2018, though... -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-30 12:14 ` Corinna Vinschen @ 2018-11-30 12:44 ` James E. King III 2018-11-30 12:56 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: James E. King III @ 2018-11-30 12:44 UTC (permalink / raw) To: cygwin On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen <corinna-cygwin@cygwin.com> wrote: > > On Nov 29 17:38, James E. King III wrote: > > On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen > > > I created a patch and uploaded new developer snapshots to > > > https://cygwin.com/snapshots/ Please give them a try. > > > > This fixed the issue for me. What's the best way to detect cygwin > > with this support? > > This will show up in version 2.12.0(*) so checking the release field > from uname(2) should do the trick. Is there a programmatic way to check this without having to parse a bunch of char[20] from utsname.h? - Jim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-30 12:44 ` James E. King III @ 2018-11-30 12:56 ` Corinna Vinschen 2018-12-01 4:27 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-11-30 12:56 UTC (permalink / raw) To: cygwin; +Cc: James E. King III [-- Attachment #1: Type: text/plain, Size: 802 bytes --] On Nov 30 07:43, James E. King III wrote: > On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen > <corinna-cygwin@cygwin.com> wrote: > > > > On Nov 29 17:38, James E. King III wrote: > > > On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen > > > > I created a patch and uploaded new developer snapshots to > > > > https://cygwin.com/snapshots/ Please give them a try. > > > > > > This fixed the issue for me. What's the best way to detect cygwin > > > with this support? > > > > This will show up in version 2.12.0(*) so checking the release field > > from uname(2) should do the trick. > > Is there a programmatic way to check this without having to parse a > bunch of char[20] from utsname.h? How would you do this on Linux? Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-11-30 12:56 ` Corinna Vinschen @ 2018-12-01 4:27 ` Brian Inglis 2018-12-01 9:53 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2018-12-01 4:27 UTC (permalink / raw) To: cygwin On 2018-11-30 05:56, Corinna Vinschen wrote: > On Nov 30 07:43, James E. King III wrote: >> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote: >>> On Nov 29 17:38, James E. King III wrote: >>>> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote: >>>>> I created a patch and uploaded new developer snapshots to >>>>> https://cygwin.com/snapshots/ Please give them a try. >>>> This fixed the issue for me. What's the best way to detect cygwin >>>> with this support? >>> This will show up in version 2.12.0(*) so checking the release field >>> from uname(2) should do the trick. >> Is there a programmatic way to check this without having to parse a >> bunch of char[20] from utsname.h? > How would you do this on Linux? Same: https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c - read /proc/version which is generated from utsname fields (or vice versa) using e.g fscanf $ head /proc/version CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (corinna@calimero.vinschen.de) (gcc version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34 - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable): $ head /{etc,usr/lib}/os-release ==> /etc/os-release <== PRETTY_NAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ==> /usr/lib/os-release <== ... [same] Could also be supported under Cygwin: $ cyg-os-release.sh | tee /usr/lib/os-release PRETTY_NAME="Cygwin 64 2.11.2 2018-11-08" NAME=Cygwin ID=cygwin ID_LIKE=msys mingw VARIANT="64" VARIANT_ID="x86_64" VERSION="2.11.2 (0.329/5/3) 2018-11-08 14:34" VERSION_ID="2.11.2" BUILD_ID="0.329/5/3 2018-11-08 14:34" CPE_NAME="cpe:/a:cygwin:cygwin:2.11.2::~~~~x64~Windows%3e%3d6.0" HOME_URL="https://cygwin.com/" SUPPORT_URL="https://cygwin.com/ml/cygwin/" BUG_REPORT_URL="https://cygwin.com/ml/cygwin/" $ (cd /etc; ln -fsv ../usr/lib/os-release .) './os-release' -> '../usr/lib/os-release' -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-12-01 4:27 ` Brian Inglis @ 2018-12-01 9:53 ` Corinna Vinschen 2018-12-01 15:49 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2018-12-01 9:53 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1952 bytes --] On Nov 30 21:27, Brian Inglis wrote: > On 2018-11-30 05:56, Corinna Vinschen wrote: > > On Nov 30 07:43, James E. King III wrote: > >> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote: > >>> On Nov 29 17:38, James E. King III wrote: > >>>> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote: > >>>>> I created a patch and uploaded new developer snapshots to > >>>>> https://cygwin.com/snapshots/ Please give them a try. > >>>> This fixed the issue for me. What's the best way to detect cygwin > >>>> with this support? > >>> This will show up in version 2.12.0(*) so checking the release field > >>> from uname(2) should do the trick. > >> Is there a programmatic way to check this without having to parse a > >> bunch of char[20] from utsname.h? > > How would you do this on Linux? > > Same: > https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c > > - read /proc/version which is generated from utsname fields (or vice versa) > using e.g fscanf > > $ head /proc/version > CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (corinna@calimero.vinschen.de) (gcc > version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34 > > - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable): > > $ head /{etc,usr/lib}/os-release > ==> /etc/os-release <== > PRETTY_NAME="Debian GNU/Linux 9 (stretch)" > NAME="Debian GNU/Linux" > VERSION_ID="9" > VERSION="9 (stretch)" > ID=debian > HOME_URL="https://www.debian.org/" > SUPPORT_URL="https://www.debian.org/support" > BUG_REPORT_URL="https://bugs.debian.org/" > > ==> /usr/lib/os-release <== > ... [same] > > Could also be supported under Cygwin: We don't have OS releases. Every component in Cygwin has its own release cycle and the version number of the Cygwin DLL is *not* a os release number. What sense would this file have for us? Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-12-01 9:53 ` Corinna Vinschen @ 2018-12-01 15:49 ` Brian Inglis 2018-12-02 11:34 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: Brian Inglis @ 2018-12-01 15:49 UTC (permalink / raw) To: cygwin On 2018-12-01 02:53, Corinna Vinschen wrote: > On Nov 30 21:27, Brian Inglis wrote: >> On 2018-11-30 05:56, Corinna Vinschen wrote: >>> On Nov 30 07:43, James E. King III wrote: >>>> On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen wrote: >>>>> On Nov 29 17:38, James E. King III wrote: >>>>>> On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote: >>>>>>> I created a patch and uploaded new developer snapshots to >>>>>>> https://cygwin.com/snapshots/ Please give them a try. >>>>>> This fixed the issue for me. What's the best way to detect cygwin >>>>>> with this support? >>>>> This will show up in version 2.12.0(*) so checking the release field >>>>> from uname(2) should do the trick. >>>> Is there a programmatic way to check this without having to parse a >>>> bunch of char[20] from utsname.h? >>> How would you do this on Linux? >> >> Same: >> https://stackoverflow.com/questions/46280456/check-kernel-version-at-runtime-in-c >> >> - read /proc/version which is generated from utsname fields (or vice versa) >> using e.g fscanf >> >> $ head /proc/version >> CYGWIN_NT-10.0 version 2.11.2(0.329/5/3) (corinna@calimero.vinschen.de) (gcc >> version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34 >> >> - read (or source) /{etc,usr/lib}/os-release VERSION_ID line (or variable): >> >> $ head /{etc,usr/lib}/os-release >> ==> /etc/os-release <== >> PRETTY_NAME="Debian GNU/Linux 9 (stretch)" >> NAME="Debian GNU/Linux" >> VERSION_ID="9" >> VERSION="9 (stretch)" >> ID=debian >> HOME_URL="https://www.debian.org/" >> SUPPORT_URL="https://www.debian.org/support" >> BUG_REPORT_URL="https://bugs.debian.org/" >> >> ==> /usr/lib/os-release <== >> ... [same] >> >> Could also be supported under Cygwin: > > We don't have OS releases. Every component in Cygwin has its own > release cycle and the version number of the Cygwin DLL is *not* a > os release number. What sense would this file have for us? Cygwin to me is a Unix package distro which provides bits and flavours of POSIX, Linux, and BSD userlands and APIs, that happens to be based on top of Windows, and provides extensive functionality and interoperability with and under that environment, which makes it easier working for or in many orgs and with most users and systems. The Cygwin release is similar to Linux kernel versions, which may vary independent of distros and releases, but is also similar to distro releases like Debian 10 Buster or Ubuntu 19 Disco Dingo, which mark the time and progress e.g. 1.0 (RTM), 1.5 (Legacy), 1.7 (No9x/IPv6/LSA/charsets/IPC), 2.0 (NoPasswd), 2.5.2 (LastXP), 2.6 (PostXP/Locales), 2.10 (NoKR/ssp/FORTIFY), ... in somewhat arbitrary steps. The file centralizes and standardizes distro info previously spread across multiple files in some distros (four on Fedora) with many names depending on distros: /etc/*[-_]{release,version} and can be handy identifying in scripts, on logs, or creating/selecting network directories, where something was run or originated; see: http://0pointer.de/blog/projects/os-release https://www.freedesktop.org/software/systemd/man/os-release.html That's valuable for and to system/net/db support staff who have to support diverse legacy (in the sense of not the current corp standard distro or release) systems or contract/external staff who have to support multiple orgs with different standard distros or releases. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early 2018-12-01 15:49 ` Brian Inglis @ 2018-12-02 11:34 ` Corinna Vinschen 0 siblings, 0 replies; 13+ messages in thread From: Corinna Vinschen @ 2018-12-02 11:34 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 2090 bytes --] On Dec 1 08:49, Brian Inglis wrote: > On 2018-12-01 02:53, Corinna Vinschen wrote: > > On Nov 30 21:27, Brian Inglis wrote: > >> $ head /{etc,usr/lib}/os-release > >> ==> /etc/os-release <== > >> PRETTY_NAME="Debian GNU/Linux 9 (stretch)" > >> NAME="Debian GNU/Linux" > >> VERSION_ID="9" > >> VERSION="9 (stretch)" > >> ID=debian > >> HOME_URL="https://www.debian.org/" > >> SUPPORT_URL="https://www.debian.org/support" > >> BUG_REPORT_URL="https://bugs.debian.org/" > >> > >> ==> /usr/lib/os-release <== > >> ... [same] > >> > >> Could also be supported under Cygwin: > > > > We don't have OS releases. Every component in Cygwin has its own > > release cycle and the version number of the Cygwin DLL is *not* a > > os release number. What sense would this file have for us? > > Cygwin to me is a Unix package distro which provides bits and flavours of POSIX, > Linux, and BSD userlands and APIs, that happens to be based on top of Windows, > and provides extensive functionality and interoperability with and under that > environment, which makes it easier working for or in many orgs and with most > users and systems. > > The Cygwin release is similar to Linux kernel versions, which may vary > independent of distros and releases, but is also similar to distro releases like > Debian 10 Buster or Ubuntu 19 Disco Dingo, which mark the time and progress e.g. > 1.0 (RTM), 1.5 (Legacy), 1.7 (No9x/IPv6/LSA/charsets/IPC), 2.0 (NoPasswd), 2.5.2 > (LastXP), 2.6 (PostXP/Locales), 2.10 (NoKR/ssp/FORTIFY), ... in somewhat > arbitrary steps. But this is all Cygwin DLL version. Nothing of that is related to any kind of distro version number. All other packages have their own, entirely disconnected rolling release cycle. If you like you can provide an os-release package with this file. However, it would be kind of static: NAME=Cygwin VERSION="42" ID=cygwin VERSION_ID=42 PRETTY_NAME="Cygwin" HOME_URL="https://cygwin.com/" SUPPORT_URL="https://cygwin.com/" Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2018-12-02 11:34 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-25 14:01 pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early James E. King III 2018-11-26 15:35 ` Corinna Vinschen 2018-11-26 15:47 ` James E. King III 2018-11-26 16:47 ` Corinna Vinschen 2018-11-29 10:18 ` Corinna Vinschen 2018-11-29 22:39 ` James E. King III 2018-11-30 12:14 ` Corinna Vinschen 2018-11-30 12:44 ` James E. King III 2018-11-30 12:56 ` Corinna Vinschen 2018-12-01 4:27 ` Brian Inglis 2018-12-01 9:53 ` Corinna Vinschen 2018-12-01 15:49 ` Brian Inglis 2018-12-02 11:34 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).