Discussion:
pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
James E. King III
2018-11-25 14:01:10 UTC
Permalink
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
***@pulsar /cygdrive/c/users/jim/desktop
$ ./timed_wait_short.exe
begin: 521052s 95953200n
target: 521052s 145953200n
end: 521052s 145284000n
ok: false
***@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
Corinna Vinschen
2018-11-26 15:35:45 UTC
Permalink
Post by James E. King III
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
James E. King III
2018-11-26 15:47:38 UTC
Permalink
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
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.
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
Corinna Vinschen
2018-11-26 16:46:57 UTC
Permalink
Post by James E. King III
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
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.
[...]
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
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
Corinna Vinschen
2018-11-29 10:18:21 UTC
Permalink
Post by Corinna Vinschen
Post by James E. King III
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
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.
[...]
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
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?
- 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
James E. King III
2018-11-29 22:38:47 UTC
Permalink
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
Post by Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
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.
[...]
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
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?
- 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
Corinna Vinschen
2018-11-30 12:14:29 UTC
Permalink
Post by James E. King III
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
Post by 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
James E. King III
2018-11-30 12:43:51 UTC
Permalink
On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
Post by 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
Corinna Vinschen
2018-11-30 12:56:33 UTC
Permalink
Post by James E. King III
On Fri, Nov 30, 2018 at 7:23 AM Corinna Vinschen
Post by Corinna Vinschen
Post by James E. King III
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
Post by 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
Brian Inglis
2018-12-01 04:27:40 UTC
Permalink
Post by Corinna Vinschen
Post by James E. King III
Post by Corinna Vinschen
Post by James E. King III
Post by 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?
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) (***@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
Corinna Vinschen
2018-12-01 09:53:22 UTC
Permalink
Post by Brian Inglis
Post by Corinna Vinschen
Post by James E. King III
Post by Corinna Vinschen
Post by James E. King III
Post by 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?
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
version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34
$ 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]
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
Brian Inglis
2018-12-01 15:49:26 UTC
Permalink
Post by Corinna Vinschen
Post by Brian Inglis
Post by Corinna Vinschen
Post by James E. King III
Post by Corinna Vinschen
Post by James E. King III
Post by 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?
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
version 7.3.0 20180125 (Fedora Cygwin 7.3.0-2) (GCC) ) 2018-11-08 14:34
$ 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]
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
Corinna Vinschen
2018-12-02 11:34:44 UTC
Permalink
Post by Brian Inglis
Post by Corinna Vinschen
Post by Brian Inglis
$ 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]
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
Loading...