Re: Cygwin Git with Windows paths
> On Nov 27, 2018, at 8:09 AM, Steven Penny wrote: > > On Mon, 26 Nov 2018 22:54:14, Adam Dinwoodie wrote: >> Personally, I don't see this as a bug; AIUI using Windows style paths >> isn't something that is supported in general in Cygwin, even if it's >> something that works in some circumstances. > > It is a bug. Even when you use Unix paths, Cygwin is doing path conversions: It's not a bug. Cygwin has been on record for a very long time that Windows paths might work, but since it's emulating Linux, they are not guaranteed to work. If they work, great. If they don't work, too bad. Some maintainers try to keep them working in their respective programs, but that is a courtesy, not fixing a bug. -- 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: Cygwin Git with Windows paths
On Mon, 26 Nov 2018 22:54:14, Adam Dinwoodie wrote: Personally, I don't see this as a bug; AIUI using Windows style paths isn't something that is supported in general in Cygwin, even if it's something that works in some circumstances. It is a bug. Even when you use Unix paths, Cygwin is doing path conversions: $ ls /var cache lib log run tmp $ strace ls /var | grep -E '(conv_to|normalize)_(posix|win32)_path' | wc 32 3203337 So either this code should be pulled out of the Cygwin DLL, or people should stop saying that its not supported. I see you've raised this on the Git mailing list as well, and if the upstream Git package starts to handle such paths, I'll take the relevant patches. However since I don't consider this a bug, I'm not going to raise it myself. Its not fixed upstream (yet), but a patch is available that fixes the issue: http://public-inbox.org/git/20181126173252.1558-1-tbo...@web.de Note carefully that Windows path handling previously worked with Cygwin Git until Dec 2016, when a patch was introduced that broke that use case. The patch in question repairs the path handling so that Unix and Windows paths are both supported with Cygwin Git again. -- 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: mintty slow refresh rate over RDP
Am 26.11.2018 um 23:36 schrieb L A Walsh: On 11/26/2018 12:20 PM, David Dombrowsky wrote: --- I find best results hosting the GUI (the window of the TTY) on the local machine, and only transfering the data (the txt of the ssh session). On of the features you might want to use for your situation, though, is make sure "jump-scroll" is turned on if it is not. Otherwise any terminal program might take a very long time to catch up. It really is an expensive operation to scroll text on a remote machine. Early HW terminals and PC screens used special hardware to perform scrolling at fast speed. Performing a smooth scroll via bit-moves of memory would be VERY painful on older machines or current machines using a slow-enough remote interface. Mintty does not support smooth scrolling. (I gave it a try once but there is no complete implementation.) Try running xterm locally and make sure TERM is set correctly on the remote machine and I think you may be happier with the performance and "feel"... A good suggestion anyway. However, if you provide instructions on how to reproduce the issue, I may find time to check out whether there is some improvement potential. Thomas -- 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: Cygwin Git with Windows paths
On Sun, 18 Nov 2018 at 06:07, Steven Penny wrote: > > Cygwin Git can clone with Unix form paths: > > $ git clone git://github.com/benhoyt/goawk /tmp/goawk > Cloning into '/tmp/goawk'... > remote: Enumerating objects: 330, done. > > However it fails with Windows form: > > $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk' > Cloning into 'C:\cygwin64\tmp\goawk'... > fatal: Invalid path '/home/Steven/C:\cygwin64\tmp\goawk': No such file or > directory > > and mixed form: > > $ git clone git://github.com/benhoyt/goawk C:/cygwin64/tmp/goawk > fatal: Invalid path '/home/Steven/C:/cygwin64': No such file or directory > > Note that other Cygwin programs work fine with these forms: > > $ ls 'C:\cygwin64' > bin Cygwin.ico dev home sbin usr > Cygwin.bat Cygwin-Terminal.ico etc lib tmp var > > This causes problems for any non-Cygwin tools that might call Git: > > http://github.com/golang/go/issues/23155 Personally, I don't see this as a bug; AIUI using Windows style paths isn't something that is supported in general in Cygwin, even if it's something that works in some circumstances. I acknowledge that this causes problems for non-Cygwin tools using Cygwin Git, but the solution there is to either use Cygwin aware/native versions of those tools, or to use non-Cygwin versions of Git. In particular, I'm wary of fixing this set of interop problem introducing some other problem; I'd prefer Cygwin tools to fail to handle Windows paths entirely than the current situation where "c:" refers to a file of that exact name in the current directory, and "c:\" sometimes refers to a completely different directory, when on *nix systems in general both would refer to files in the current directory. I see you've raised this on the Git mailing list as well, and if the upstream Git package starts to handle such paths, I'll take the relevant patches. However since I don't consider this a bug, I'm not going to raise it myself. Adam -- 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: mintty slow refresh rate over RDP
On 11/26/2018 12:20 PM, David Dombrowsky wrote: mintty is the only non-X11 terminal emulator in the stack, correct? --- I find best results hosting the GUI (the window of the TTY) on the local machine, and only transfering the data (the txt of the ssh session). On of the features you might want to use for your situation, though, is make sure "jump-scroll" is turned on if it is not. Otherwise any terminal program might take a very long time to catch up. It really is an expensive operation to scroll text on a remote machine. Early HW terminals and PC screens used special hardware to perform scrolling at fast speed. Performing a smooth scroll via bit-moves of memory would be VERY painful on older machines or current machines using a slow-enough remote interface. Try running xterm locally and make sure TERM is set correctly on the remote machine and I think you may be happier with the performance and "feel"... -- 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: tar cygwin64/ from old to new computer?
Am 26.11.2018 um 21:32 schrieb Gilbert St. Firmin: > Could the native Windows version of 7-zip be used on both old and new > computers? Possibly. If that can be taught to copy all the attributes used by Cygwin, without running into the usual problems we see whenever Windows tools are used to handle those. But I really very much doubt it. This really is a full blown chicken-and-egg situation: the only tools really known to be able to correctly copy Cygwin files including all their ACLs are Cygwin itself, and its installer. All other tools are suspect. It all comes back down to what I wrote in my initial answer: is remote access to a Cygwin mirror server really so much slower than your local network that there's even any gain to be had from going this untested route? I.e. why even risk this? -- 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: tar cygwin64/ from old to new computer?
On: Sun, 25 Nov 2018 18:08:35 +0100, Hans-Bernhard Bröker wrote: You're overlooking a chicken-and-egg problem there: your new computer has no 'tar' to unpack that file. Could the native Windows version of 7-zip be used on both old and new computers? Also, perhaps the Windows Image Format (WIM) could be used instead, presuming UUIDs would not be an issue if both computers shared identical machine names and accounts. Just curious. Gilbert P. St. Firmin -- 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: mintty slow refresh rate over RDP
On 11/26/18 1:25 PM, Stefan Baur wrote: > Am 26.11.18 um 19:16 schrieb David Dombrowsky: >> Anyone know which part is messing up here? This doesn't happen playing >> videos or other graphically intensive programs. Only the cygwin >> terminal. Anyone have any ideas? > > As far as I know, rdesktop still uses an older version of the RDP > protocol, so you might want to try FreeRDP (xfreerdp on most Linuxes I > know) and take a good look at the options it supports for speeding up > the screen updates. You are correct. There are different results using different clients. All of them present some level of the issue, though. mintty is the only non-X11 terminal emulator in the stack, correct? -- David Dombrowsky, Software Engineer da...@6thstreetradio.org | 518-374-3204 https://www.linkedin.com/in/david-dombrowsky-94334415 -- 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
[ITP] libcerf
I want to introduce libcerf to Cygwin as a new dependency for gnuplot. Upstream recently moved from autotools to cmake and in the process removed the pkg-config integration, but gnuplot resolves its presence anyway. --8<---cut here---start->8--- root=http://cygwin.stromeko.net/ repo=$root/maint/$arch/release/libcerf $repo/libcerf-1.7-1-src.tar.xz $repo/libcerf-1.7-1.hint $repo/libcerf-debuginfo/libcerf-debuginfo-1.7-1.hint $repo/libcerf-debuginfo/libcerf-debuginfo-1.7-1.tar.xz $repo/libcerf-devel/libcerf-devel-1.7-1.hint $repo/libcerf-devel/libcerf-devel-1.7-1.tar.xz $repo/libcerf-doc/libcerf-doc-1.7-1.hint $repo/libcerf-doc/libcerf-doc-1.7-1.tar.xz $repo/libcerf1/libcerf1-1.7-1.hint $repo/libcerf1/libcerf1-1.7-1.tar.xz --8<---cut here---end--->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: tar cygwin64/ from old to new computer:
On 11/25/2018 11:58 AM, Andrey Repin wrote: Greetings, L A Walsh! --- Hmm...can't tar it, but he could drag from Explorer like he was moving the image (but do a copy instead). It would screw permissions on Cygwin files/directories. --- Perhaps, I haven't tried this particular use case, however, usually it just duplicates them. Think about the local case. There it just does a rename. I don't think they would deliberately allow custom ACL's to be tossed just because the copy was to a different device. But, once you had the files in place, wouldn't an rsync from old to new, fix up just the ACL's? If rsync won't work, then use "cp": > cp -rd --attributes-only /old /new Is there a reason why that wouldn't (or shouldn't) work? -- 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: setup-x86_64 Can't Download to Mapped Drive
On 11/26/2018 6:38 AM, Andrey Repin wrote: Greetings, Sridhar Ayengar! I am trying to use a network shared drive mapped to I: for the download directory, I:\cygwindownload. setup-x86_64 shows a dialog box with "Directory I:\cygwindownload does not exist, would you like me to create it?". .. Get off the habit of using mapped drives. Use UNC paths directly. Why? UNC drives are the linux equivalent of a local alias of a local "mount --bind //net/dir /i/". Would you tell linux users to get off the habit of using mount with bind? I have used Cygwin since Windows_XP with my Cygwin package cache on a mapped drive (and have it installed at C:\ with a drive prefix of '/', so '/c' == '/': cd 'S:/Software/Cygwin' /s/Software/Cygwin> more setup.log.full 2018/11/02 15:32:27 Starting cygwin install, version 2.891 2018/11/02 15:32:27 User has backup/restore rights 2018/11/02 15:32:27 Current Directory: S:\Software\Cygwin 2018/11/02 15:32:27 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. 2018/11/02 15:32:30 Ending cygwin install net use S: Local nameS: Remote name \\Ishtar\Share Resource type Disk I have never had a problem with it being remote. FWIW, my cygwin signon is in the Administrators group as well as my local domain (hosted on linux)'s "Domain Admins" group. Second point (not sure if it is important or not), my local sys account 'Administrator' has the same mappings as my main login. -- 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
32 bit vs 64 bit Cygwin, followup
Hello everybody, In this message (https://www.sourceware.org/ml/cygwin/2018-11/msg00190.html), Corinna (Hi Corinna!) says: "Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause." I would like to mention why I am still using 32 bit Cygwin. I maintain a port of a database called GT.M (https://en.wikipedia.org/wiki/GT.M) on Cygwin. I work with Electronic Medical Records that run on this database. GT.M contains a large amount of assembly code, written to run on the x32 Linux ABI and the AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI, which is very different than the AMD ABI (more detail here: https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/). I don't have the expertise nor the time to rewrite a lot of assembly code to use the Windows x64 ABI. There are about 100 source code files that are in assembly. By the way, thank you for the Async IO APIs. I needed those for newer versions of GT.M and was able to port it successfully to Cygwin x32. --Sam -- 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: mintty slow refresh rate over RDP
Am 26.11.18 um 19:16 schrieb David Dombrowsky: > Anyone know which part is messing up here? This doesn't happen playing > videos or other graphically intensive programs. Only the cygwin > terminal. Anyone have any ideas? As far as I know, rdesktop still uses an older version of the RDP protocol, so you might want to try FreeRDP (xfreerdp on most Linuxes I know) and take a good look at the options it supports for speeding up the screen updates. Kind Regards, Stefan Baur -- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -- 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
mintty slow refresh rate over RDP
I might the only one in the world to run into this, but it happens so often that I need to ask the question. I connect over a LAN to a windows box from my linux machine using `rdesktop`. I then launch a cygwin terminal window using the normal shortcut, which launches mintty.exe. If I then run a build of something, which scrolls a reasonable amount of data to the screen, rdesktop then freaks out for a while trying to constantly redraw the mintty window. Sometimes I have to wait for the build to finish before I can even minimize the window. Anyone know which part is messing up here? This doesn't happen playing videos or other graphically intensive programs. Only the cygwin terminal. Anyone have any ideas? -- David Dombrowsky, Software Engineer da...@6thstreetradio.org | 518-374-3204 https://www.linkedin.com/in/david-dombrowsky-94334415 -- 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: No thread safety in clock_gettime (hires_ns::prime)
On Mon, 26 Nov 2018 18:01:40, Corinna Vinschen wrote:
>
> On Nov 23 11:27, James E. King III wrote:
[snip]
> > I found that a call to
> > clock_gettime(CLOCK_MONOTONIC, ..) has a one-time initialization that
> > is not thread-safe. If two threads call this at the same time, they
> > will race. The results I am seeing are typically that one of the two
> > callers get a timespec structure with zero values, and no error return
> > code from the call.
>
> Thanks for the testcase, but I can't reproduce the problem, neither on
> 32 bit nor on 64 bit. I tweaked your makefile to have a 100K loop I
> started multiple times with differently optimzed code, but to no avail.
>
> To account for that, I inspected the code doing the initialization and
> found that it uses REALTIME priority when trying to make sure multiple
> threads don't collide. This is a bit on the dangerous side, apparently.
>
> I tweaked the code to use a spinlock instead.
>
> I'm just about to upload new developer snapshots to
> https://cygwin.com/snapshots/
>
> Should be up in 10 mins or so. Can you please try if this fixes the
> problem for you?
- only replaced the cygwin1.dll ...
Henri
64-@@ uname -a
CYGWIN_NT-6.1 Seven 2.11.3(0.329/5/3) x86_64 Cygwin
64-@@ ls -l /bin/cygwin1*
-rwxr-xr-x 1 Henri None 3339661 Nov 8 14:36 /bin/cygwin1-2.11.2.X
-rwxr-xr-x 1 Henri None 3337995 Nov 26 18:43 /bin/cygwin1-64-20181126.X
-rwxr-xr-x 1 Henri None 3337995 Nov 26 18:43 /bin/cygwin1.dll
64-@@ cd threads
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ make test
64-@@ vi Makefile
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ #... wait a while ...
64-@@ for loop in {1..100}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..1000}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..1000}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..1000}; do ./cyg_hires_clock_race.exe; done
64-@@ for loop in {1..1}; do ./cyg_hires_clock_race.exe; done
64-@@# That is enough!
=
--
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: No thread safety in clock_gettime (hires_ns::prime)
Greetings, Corinna Vinschen! > On Nov 23 11:27, James E. King III wrote: >> Using 32-bit cygwin that I set up yesterday. > Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost > cause. Not until manufacturers stop selling 32-bit systems. -- With best regards, Andrey Repin Monday, November 26, 2018 20:50:31 Sorry for my terrible english... -- 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: No thread safety in clock_gettime (hires_ns::prime)
On Mon, 26 Nov 2018 18:01:40, Corinna Vinschen wrote: > > On Nov 23 11:27, James E. King III wrote: [snip] > > I found that a call to > > clock_gettime(CLOCK_MONOTONIC, ..) has a one-time initialization that > > is not thread-safe. If two threads call this at the same time, they > > will race. The results I am seeing are typically that one of the two > > callers get a timespec structure with zero values, and no error return > > code from the call. > > Thanks for the testcase, but I can't reproduce the problem, neither on > 32 bit nor on 64 bit. I tweaked your makefile to have a 100K loop I > started multiple times with differently optimzed code, but to no avail. I can, easily. (Windows 7, 64-bits. Unmodified Makefile.) Henri -- 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: No thread safety in clock_gettime (hires_ns::prime)
On 11/26/2018 12:01 PM, Corinna Vinschen wrote: On Nov 23 11:27, James E. King III wrote: Using 32-bit cygwin that I set up yesterday. Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause. When exactly will it be a lost cause for Cygwin? I.E. Are you planning to discontinue maintenance for 32bit anytime soon? Anyone needing it could continue to use the existing distribution. I ask only because I agree with your statement that it is a lost cause. -- cyg Simple -- 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: No thread safety in clock_gettime (hires_ns::prime)
On Nov 23 11:27, James E. King III wrote: > Using 32-bit cygwin that I set up yesterday. Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause. > I found that a call to > clock_gettime(CLOCK_MONOTONIC, ..) has a one-time initialization that > is not thread-safe. If two threads call this at the same time, they > will race. The results I am seeing are typically that one of the two > callers get a timespec structure with zero values, and no error return > code from the call. Thanks for the testcase, but I can't reproduce the problem, neither on 32 bit nor on 64 bit. I tweaked your makefile to have a 100K loop I started multiple times with differently optimzed code, but to no avail. To account for that, I inspected the code doing the initialization and found that it uses REALTIME priority when trying to make sure multiple threads don't collide. This is a bit on the dangerous side, apparently. I tweaked the code to use a spinlock instead. I'm just about to upload new developer snapshots to https://cygwin.com/snapshots/ Should be up in 10 mins or so. Can you please try if this fixes the problem for you? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
[newlib-cygwin] Cygwin: timers: use spinlock to prime hires_ns thread-safe
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5eaa64f9d86cae422016c3b08476b1cea556628e
commit 5eaa64f9d86cae422016c3b08476b1cea556628e
Author: Corinna Vinschen
Date: Mon Nov 26 17:47:53 2018 +0100
Cygwin: timers: use spinlock to prime hires_ns thread-safe
The current method to make hires_ns priming thread-safe isn't
thread-safe. Rather than hoping that running the thread in
TIME_CRITICAL priority is doing the right thing, use a spinlock.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/hires.h | 2 +-
winsup/cygwin/times.cc | 26 --
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/winsup/cygwin/hires.h b/winsup/cygwin/hires.h
index d07bf39..10aed7b 100644
--- a/winsup/cygwin/hires.h
+++ b/winsup/cygwin/hires.h
@@ -40,7 +40,7 @@ details. */
class hires_ns
{
- int inited;
+ LONG inited;
LARGE_INTEGER primed_pc;
double freq;
void prime ();
diff --git a/winsup/cygwin/times.cc b/winsup/cygwin/times.cc
index 1ead18e..4e405b2 100644
--- a/winsup/cygwin/times.cc
+++ b/winsup/cygwin/times.cc
@@ -24,6 +24,7 @@ details. */
#include "thread.h"
#include "cygtls.h"
#include "ntdll.h"
+#include "spinlock.h"
hires_ms NO_COPY gtod;
@@ -465,19 +466,16 @@ ftime (struct timeb *tp)
void
hires_ns::prime ()
{
- LARGE_INTEGER ifreq;
-
- /* On XP or later the perf counter functions will always succeed. */
- QueryPerformanceFrequency ();
-
- int priority = GetThreadPriority (GetCurrentThread ());
-
- SetThreadPriority (GetCurrentThread (), THREAD_PRIORITY_TIME_CRITICAL);
- QueryPerformanceCounter (_pc);
+ spinlock hspin (inited, 1);
+ if (!hspin)
+{
+ LARGE_INTEGER ifreq;
- freq = (double) ((double) NSPERSEC / (double) ifreq.QuadPart);
- inited = true;
- SetThreadPriority (GetCurrentThread (), priority);
+ /* On XP or later the perf counter functions will always succeed. */
+ QueryPerformanceFrequency ();
+ freq = (double) ((double) NSPERSEC / (double) ifreq.QuadPart);
+ QueryPerformanceCounter (_pc);
+}
}
LONGLONG
@@ -485,7 +483,7 @@ hires_ns::nsecs (bool monotonic)
{
LARGE_INTEGER now;
- if (!inited)
+ if (inited <= 0)
prime ();
QueryPerformanceCounter ();
// FIXME: Use round() here?
@@ -627,7 +625,7 @@ static ULONG minperiod; // FIXME: Maintain period after
a fork.
LONGLONG
hires_ns::resolution ()
{
- if (!inited)
+ if (inited <= 0)
prime ();
return (freq <= 1.0) ? 1LL : (LONGLONG) freq;
}
[newlib-cygwin] Cygwin: timers: Simplify hires_ms and hires_ns
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=65091f0f35b29d5a043630fd877f0314a0779fb6
commit 65091f0f35b29d5a043630fd877f0314a0779fb6
Author: Corinna Vinschen
Date: Mon Nov 26 17:24:35 2018 +0100
Cygwin: timers: Simplify hires_ms and hires_ns
Drop hires_base and move inited into hires_ns.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/hires.h | 11 ++-
winsup/cygwin/times.cc | 2 --
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/winsup/cygwin/hires.h b/winsup/cygwin/hires.h
index 04ee606..d07bf39 100644
--- a/winsup/cygwin/hires.h
+++ b/winsup/cygwin/hires.h
@@ -38,16 +38,9 @@ details. */
/* # of millisecs per second. */
#define MSPERSEC (1000L)
-class hires_base
+class hires_ns
{
- protected:
int inited;
- public:
- void reset() {inited = false;}
-};
-
-class hires_ns : public hires_base
-{
LARGE_INTEGER primed_pc;
double freq;
void prime ();
@@ -57,7 +50,7 @@ class hires_ns : public hires_base
LONGLONG resolution();
};
-class hires_ms : public hires_base
+class hires_ms
{
public:
LONGLONG nsecs ();
diff --git a/winsup/cygwin/times.cc b/winsup/cygwin/times.cc
index 11fb8f2..e890514 100644
--- a/winsup/cygwin/times.cc
+++ b/winsup/cygwin/times.cc
@@ -120,8 +120,6 @@ settimeofday (const struct timeval *tv, const struct
timezone *tz)
st.wMilliseconds = tv->tv_usec / (USPERSEC / MSPERSEC);
res = -!SetSystemTime ();
- gtod.reset ();
-
if (res)
set_errno (EPERM);
}
[newlib-cygwin] Cygwin: timers: drop error handling for Windows perf timer functions
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=161d0fd27bdedcf5ff9ea2a56596a3b1ce368d74
commit 161d0fd27bdedcf5ff9ea2a56596a3b1ce368d74
Author: Corinna Vinschen
Date: Mon Nov 26 17:38:15 2018 +0100
Cygwin: timers: drop error handling for Windows perf timer functions
Per MSDN, the perf timer functions always succeed on Windows XP or
later.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/times.cc | 37 +++--
1 file changed, 7 insertions(+), 30 deletions(-)
diff --git a/winsup/cygwin/times.cc b/winsup/cygwin/times.cc
index e890514..1ead18e 100644
--- a/winsup/cygwin/times.cc
+++ b/winsup/cygwin/times.cc
@@ -466,21 +466,14 @@ void
hires_ns::prime ()
{
LARGE_INTEGER ifreq;
- if (!QueryPerformanceFrequency ())
-{
- inited = -1;
- return;
-}
+
+ /* On XP or later the perf counter functions will always succeed. */
+ QueryPerformanceFrequency ();
int priority = GetThreadPriority (GetCurrentThread ());
SetThreadPriority (GetCurrentThread (), THREAD_PRIORITY_TIME_CRITICAL);
- if (!QueryPerformanceCounter (_pc))
-{
- SetThreadPriority (GetCurrentThread (), priority);
- inited = -1;
- return;
-}
+ QueryPerformanceCounter (_pc);
freq = (double) ((double) NSPERSEC / (double) ifreq.QuadPart);
inited = true;
@@ -490,21 +483,11 @@ hires_ns::prime ()
LONGLONG
hires_ns::nsecs (bool monotonic)
{
- if (!inited)
-prime ();
- if (inited < 0)
-{
- set_errno (ENOSYS);
- return (LONGLONG) -1;
-}
-
LARGE_INTEGER now;
- if (!QueryPerformanceCounter ())
-{
- set_errno (ENOSYS);
- return -1;
-}
+ if (!inited)
+prime ();
+ QueryPerformanceCounter ();
// FIXME: Use round() here?
now.QuadPart = (LONGLONG) (freq * (double)
(now.QuadPart - (monotonic ? 0LL : primed_pc.QuadPart)));
@@ -646,12 +629,6 @@ hires_ns::resolution ()
{
if (!inited)
prime ();
- if (inited < 0)
-{
- set_errno (ENOSYS);
- return (LONGLONG) -1;
-}
-
return (freq <= 1.0) ? 1LL : (LONGLONG) freq;
}
[newlib-cygwin] Cygwin: spinlock: remove useless get_ll call
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a094c5bafa02ac778c42ac3d85cd167fa44d88c9
commit a094c5bafa02ac778c42ac3d85cd167fa44d88c9
Author: Corinna Vinschen
Date: Mon Nov 26 17:25:47 2018 +0100
Cygwin: spinlock: remove useless get_ll call
LARGE_INTEGER has QuadPart anyway, no reason to compute the
64 bit value from HighPart and LowPart.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/winsup/cygwin/spinlock.h b/winsup/cygwin/spinlock.h
index f244355..d8ded12 100644
--- a/winsup/cygwin/spinlock.h
+++ b/winsup/cygwin/spinlock.h
@@ -30,7 +30,7 @@ class spinlock
{
LARGE_INTEGER t;
if (NtQuerySystemTime () == STATUS_SUCCESS)
- return get_ll (t);
+ return t.QuadPart;
return 0LL;
}
public:
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On Nov 26 10:47, James E. King III wrote: > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > 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 signature.asc Description: PGP signature
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen 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
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 signature.asc Description: PGP signature
Re: setup-x86_64 Can't Download to Mapped Drive
Greetings, Sridhar Ayengar! > I'm trying to use setup-x86_64.exe to update Cygwin. The directory into > which Cygwin is installed is C:\cygwin. I am trying to use a network > shared drive mapped to I: for the download directory, I:\cygwindownload. > setup-x86_64 shows a dialog box with "Directory I:\cygwindownload does not > exist, would you like me to create it?". If I click "Yes", I get a dialog > box with "Could not create directory I:\cygwindownload, sorry. (Is drive > full or read-only?)". I get the same behavior even if I remove > I:\cygwindownload and have setup-x86_64.exe try to create it. Get off the habit of using mapped drives. Use UNC paths directly. But for your specific issue, the drive mapped in your user session, but you start setup within administrative session, where the drive is not mapped. So, back to the previous statement, get off the bad habits. Or map the disk inside adm session. -- With best regards, Andrey Repin Monday, November 26, 2018 17:36:29 Sorry for my terrible english... -- 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
setup-x86_64 Can't Download to Mapped Drive
Hi! I'm trying to use setup-x86_64.exe to update Cygwin. The directory into which Cygwin is installed is C:\cygwin. I am trying to use a network shared drive mapped to I: for the download directory, I:\cygwindownload. setup-x86_64 shows a dialog box with "Directory I:\cygwindownload does not exist, would you like me to create it?". If I click "Yes", I get a dialog box with "Could not create directory I:\cygwindownload, sorry. (Is drive full or read-only?)". I get the same behavior even if I remove I:\cygwindownload and have setup-x86_64.exe try to create it. Thanks for reading. Peace... Sridhar P.S. My cygcheck.out file is too large to attach. Let me know if you need it, and I'll send it directly. P.P.S. I know it's picky, but it seems to me like the first dialog box message is a run-on-sentence. -- 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: tar cygwin64/ from old to new computer?
This may not be strictly supported, but I have been doing it for at least 10 years: Once I have a new host network accessible from the old, I simply copy c:/cygwin from old to new. Access can be via UNC, mapped drive, whatever. I normally use 'cp -a' to do the copy, but have done it other ways. (Do not use Win copy commands, they mess up links.) Then I set a few envars (by hand, via dialog box) on the new: add c:/cygwin to the PATH, set HOME and CYGWIN. I keep a home dir in cloud svn, shared across all machines, to which HOME points, which I check out onto the new, by remote. Make a couple shortcuts to start bash, mintty, like that. And up she comes. I have a file of notes to follow, but really, the above is about it. Thereafter, I run CygSetup on one machine, make sure I like it, then just copy c:/cygwin to the other machines again. (Of course, copy it first, then rename it on the dest with a DOS command, with cygwin shut down.) I do that about once a year. I have about 6 active machines -- home, work, Acure -- and this keeps them all in sync. Compared to Visual Studio and ilk, maintaining cygwin is a breeze this way. --- Karl Botts, kdbo...@usa.net -- 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: PGA 2019 List of Attendees
Hi, Greetings! Hope you had a chance to review my previous email sent. please let me know thoughts on it. Kind Regards, Mia From: Mia Fulkner Sent: 20 November 2018 09:28 To: 'cygwin@cygwin.com' Subject: PGA 2019 List of Attendees Hi, Greetings! I hope you are the right person to discuss about PGA Merchandise Show - Professional Golfers' Assn 2019 attendee info. PGA Merchandise Show - Professional Golfers' Assn 2019 attendee list of 37,500 contacts . The list will be provided for unlimited usage. Interested? Please let me know. I would love to provide more information pricing options and other information in my next email. Kind Regards, Mia Faulkner Lead Generation Executive If you don't wish to receive our newsletters, reply back with " Unsubscribe " in subject line -- 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
c3270 keymap examples
Hi, Any (Danes/Scandinavians) here using c3270? I can't get Danish national characters to work. I can't get Right Control button to be Enter(). Anyone has some good keymap examples? /Morten -- 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
