pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[James E. King III]

[-- 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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[James E. King III]

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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[James E. King III]

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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[James E. King III]

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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Brian Inglis]

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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Brian Inglis]

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

Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

[Corinna Vinschen]

[-- 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 --]