Re: Cygwin multithreading performance
Kacper Michajlow wrote: 2015-12-05 23:40 GMT+01:00 Mark Geisert : It looks like we're going to have to compare actual pthread_mutex_lock() implementations. Inspecting source is nice but I don't want to be chasing a mirage so I really hope there's a pthread_mutex_lock() function inside the MinGW git you are running. gdb could easily answer that question. Could you please do an 'info func pthread_mutex_lock' after starting MinGW git under MinGW gdb with a breakpoint at main() (so libraries are loaded). [...] Hmm, thinking about it mingw doesn't have pthread implementation or any wrapper for it. If someone needs pthread they would probably go for pthreads-w32 implementation. I started to wonder because I don't recall git would need pthreads to compile on Windows. And indeed they have a wrapper for Windows API... https://github.com/git/git/blob/master/compat/win32/pthread.h https://github.com/git/git/blob/master/compat/win32/pthread.c OK, so git has its own pthread_mutex_lock/unlock ops which map to very light-weight critical section operations. Though it is not really a matter that "native" git build is fast and all, but that Cygwin's one really struggles if it comes to MT workload. In the worst cases I see using your testcase, about half the time the busiest locks are processed within 1 usec but there's a spectrum of longer latencies for the other half of the time. I don't know (yet) if that can be improved in Cygwin's more general implementation but at least the matter has now been brought to our attention :). And this not only issue with git unfortunately. Download speeds are also limited on Cygwin. I know POSIX compatibility layers comes with a price but I would love to see improvements in those areas. Cygwin: Receiving objects: 100% (230458/230458), 78.41 MiB | 1.53 MiB/s, done. "native" git: Receiving objects: 100% (230458/230458), 78.41 MiB | 18.54 MiB/s, done. You're asserting this additional testcase has the same cause. What is telling you that? And FTR what is the git command you are issuing? I can then do the lock latency analysis on this new testcase if warranted. Thanks, ..mark -- 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: Ability to specify /cygdrive mount value in setup
Corinna Vinschen writes: > The right thing to do is to change the base-files package to utilize > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive > prefix currently in use. If these symlinks under /etc used the > /proc/cygdrive symlink, they would work all the time, independenly of > the actual cygdrive prefix. I've looked into it and I'd like to give that task back to the cygpath maintainer. :-) > Achim, any chance to tweak base-file accordingly? At the moment I'm using $(/usr/bin/cygpath -S -u) to get the system directory. Since the /cygdrive prefix could be anything, I'd either have to first figure it out via $(dirname $(/usr/bin/cygpath -u C:)) since the output from mount is a bit unwieldy. Maybe we should just force the cygdrive prefix to be /cygdrive for postinstall scripts anyway. But there really ought to be a way to simply have cygpath deliver the canonical /proc/cygdrive path instead of whatever that link points to, maybe that switch should be called "-U"? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Achim Gratz writes: > On my local laptop things look a bit different, a small ~5% subset of the > test above goes from 20s to 200s and a different larger ~10% subset from 50s > to 500s. While that hurts, the more usual case with many files from the > same user doesn't feel any slower at the moment. The access through VPN > will be interesting, though... VPN access with the worst possible terrestrial roundtrip has been tested for the same case now and goes from 52s to ~1700s or a factor of 33. So roundtrip delay adds an additional factor of about 3, but the server response time seems to play the dominant role even in that scenario. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Jemalloc under CYGWIN
On Dec 5 22:32, Yucong Sun wrote:
> I'm sorry, I got distracted from this issue and hadn't make any progress.
No worries.
> One thing specifically I need to be able to work on this issue is some
> information describing how to build/test cygwin lib (rather than using
> it). I couldn't find any information on the website, (or I havn't look
> deeply enough).
It's not complicated, really.
1. Install gcc and mingw-gcc.
2. Prepare build dir:
$ mkdir cygwin
$ cd cygwin
$ git clone git://sourceware.org/git/newlib-cygwin.git
[...]
$ mkdir build
$ cd build
3. Build:
$ export PREFIX=/usr
$ ../newlib-cygwin/configure \
--prefix=${PREFIX} \
--exec-prefix=${PREFIX} \
--bindir=${PREFIX}/bin \
--sbindir=${PREFIX}/sbin \
--libexecdir=${PREFIX}/lib \
--datadir=${PREFIX}/share \
--localstatedir=/var \
--sysconfdir=/etc \
--infodir=${PREFIX}/share/info \
--mandir=${PREFIX}/share/man \
--docdir=${PREFIX}/share/doc/cygwin \
--htmldir=${PREFIX}/share/doc/cygwin/html
$ make
# Or for debugging:
$ make CFLAGS='-gdwarf-2' CFLAGS_FOR_TARGET='-gdwarf-2'
Add -j as desired.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpQukE3mng5L.pgp
Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On Dec 6 10:58, Achim Gratz wrote: > Achim Gratz writes: > > On my local laptop things look a bit different, a small ~5% subset of the > > test above goes from 20s to 200s and a different larger ~10% subset from 50s > > to 500s. While that hurts, the more usual case with many files from the > > same user doesn't feel any slower at the moment. The access through VPN > > will be interesting, though... > > VPN access with the worst possible terrestrial roundtrip has been tested > for the same case now and goes from 52s to ~1700s or a factor of 33. So > roundtrip delay adds an additional factor of about 3, but the server > response time seems to play the dominant role even in that scenario. Uhm... is that good or bad now?!? Do you still think adding this functionality is a good idea? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgps4NDyDNd7L.pgp Description: PGP signature
Re: Ability to specify /cygdrive mount value in setup
On Dec 6 10:47, Achim Gratz wrote: > Corinna Vinschen writes: > > The right thing to do is to change the base-files package to utilize > > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive > > prefix currently in use. If these symlinks under /etc used the > > /proc/cygdrive symlink, they would work all the time, independenly of > > the actual cygdrive prefix. > > I've looked into it and I'd like to give that task back to the cygpath > maintainer. :-) > > > Achim, any chance to tweak base-file accordingly? > > At the moment I'm using $(/usr/bin/cygpath -S -u) to get the system > directory. Since the /cygdrive prefix could be anything, I'd either > have to first figure it out via $(dirname $(/usr/bin/cygpath -u C:)) > since the output from mount is a bit unwieldy. Maybe we should just > force the cygdrive prefix to be /cygdrive for postinstall scripts > anyway. No offense, but you didn't understand what I mean, it seems. Don't call cygpath. Just use /proc/cygdrive directly. It's that simple. While the cygdrive prefix changes, /proc/cygdrive will *never* change. E.g. Substitute $(dirname $(/usr/bin/cygpath -u C:)) with /proc/cygdrive/c Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpn2NnBMQqMl.pgp Description: PGP signature
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
On Dec 4 08:34, Linda Walsh wrote: > Rob van Eijk wrote: > > > >Op 1-12-2015 om 17:40 schreef David Macek: > >>On 1. 12. 2015 15:01, Corinna Vinschen wrote: > >>>If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then > >>>there's some foul-up in the WOW64 layer in terms of starting 64 bit > >>>processes, perhaps. Sigh, it's a rather unexpected change after it > >>>worked fine for so long :( > >>Yup. I can confirm. > > Win10 has a 32-bit version? > > I thought MS said Win8 was the last version that would > ship in a 32-bit version with their eventual intension to be getting > rid of 32-bit support entirely (for reasons like it supporting > various legacy design constraints that make it harder to manage(control) > as an end-user-platform, for example)? I guess given that the ARM version is 32 bit anyway, it didn't hurt to keep the 32 bit i686 version running as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgph7RxKM5YQ3.pgp Description: PGP signature
Re: Ability to specify /cygdrive mount value in setup
Corinna Vinschen writes: > No offense, but you didn't understand what I mean, it seems. I did, I think -- but read my request again. > Don't call cygpath. Just use /proc/cygdrive directly. It's that > simple. While the cygdrive prefix changes, /proc/cygdrive will > *never* change. E.g. I need cygpath to get the system directory (hint: it need not be in C:\Windows\System32) and cygpath delivers that directory with the cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all those special directories would also be available via /proc/, which means I wouldn't even need to fork cygpath for getting there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Corinna Vinschen writes: >> VPN access with the worst possible terrestrial roundtrip has been tested >> for the same case now and goes from 52s to ~1700s or a factor of 33. So >> roundtrip delay adds an additional factor of about 3, but the server >> response time seems to play the dominant role even in that scenario. > > Uhm... is that good or bad now?!? Do you still think adding this > functionality is a good idea? For most of the things I did it worked OK, so I still think AuthZ should be used. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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
[ANNOUNCEMENT] Updated: openssl-1.0.2e-1
Hi folks, I've updated the version of OpenSSL to 1.0.2e-1. This is a security bugfix release. OpenSSL Security Advisory [3 Dec 2015] === NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) == Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno Böck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) === Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) == Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) = Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Note As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade. References == URL for this Security Advisory: https://www.openssl.o
Re: Ability to specify /cygdrive mount value in setup
On 12/6/2015 9:28 AM, Achim Gratz wrote: > Corinna Vinschen writes: >> No offense, but you didn't understand what I mean, it seems. > > I did, I think -- but read my request again. > >> Don't call cygpath. Just use /proc/cygdrive directly. It's that >> simple. While the cygdrive prefix changes, /proc/cygdrive will >> *never* change. E.g. > > I need cygpath to get the system directory (hint: it need not be in > C:\Windows\System32) and cygpath delivers that directory with the > cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all > those special directories would also be available via /proc/, > which means I wouldn't even need to fork cygpath for getting there. > Use the $WINDIR variable to find the Windows path and manipulate its value to prepend /proc/cygdrive/ and suffix its value with /system32. The system32 directory will always be in $WINDIR/sytem32. -- 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: Ability to specify /cygdrive mount value in setup
Achim Gratz writes:
> I need cygpath to get the system directory (hint: it need not be in
> C:\Windows\System32) and cygpath delivers that directory with the
> cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all
> those special directories would also be available via /proc/,
> which means I wouldn't even need to fork cygpath for getting there.
This will get me the correct path to link to, but I still think it's
unnecessarily ugly (and took a while to cover all the possibilities of
not-so-well-formed cygdrive prefixes):
--8<---cut here---start->8---
CYGDRIVE="$(/usr/bin/cygpath -u C:)"
WINETC="$(/usr/bin/cygpath -S -u)/drivers/etc"
WINETC="/proc/cygdrive/${WINETC#${CYGDRIVE%c}}"
--8<---cut here---end--->8---
versus the hypothetical
--8<---cut here---start->8---
WINETC="$(/usr/bin/cygpath -S -U)/drivers/etc"
--8<---cut here---end--->8---
BTW, the path comprising the cygdrive prefix probably needs to be
sanitized to avoid things like
--8<---cut here---start->8---
$ mount -c /bla//faselblum//
--8<---cut here---end--->8---
leaking into the wild.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
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: Ability to specify /cygdrive mount value in setup
cyg Simple writes: > Use the $WINDIR variable to find the Windows path and manipulate its > value to prepend /proc/cygdrive/ and suffix its value with /system32. > The system32 directory will always be in $WINDIR/sytem32. That's just as ugly as the solution I have plus that one doesn't rely on the environment being sane. 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 -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8
Hi Cygwin friends and users, I released a new TEST version of Cygwin, 2.4.0-0.8. This adds a new feature to cygpath, the -U flag, which allows to generate /proc/cygdrive paths, which are unambiguous even if the cygdrive prefix changes. E.g.: $ mount -p Prefix Type Flags /mntuser binmode $ cygpath -D /mnt/c/Users/corinna/Desktop $ ./cygpath -DU /proc/cygdrive/c/Users/corinna/Desktop I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7 again since it's important that it gets tested: - Not a bug fix as such, but a workaround for new behaviour in Windows 10 version 1511 64 bit. This version introduces a problem which existed in a similar variation (just vice versa) in XP and Server 2003 64 bit as well. An unexpected stack arrangement when starting a 64 bit Cygwin application from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html == Please, please, please test. If this code is acceptable, I will create an official 2.4.0 release next week. == This is the "new POSIX ACL handling reloaded" release. In local testing I successfully integrated AuthZ into the current Cygwin code to generate more correct user permissions by being able to generate effective permissions for arbitrary users. This success convinced me that it might be possible to pick up the POSIX permission rewrite originally targeted for the 2.0.0 release and try to update it using AuthZ and generally revamp it to reflect effective permissions better. My local testing looks good, but this is a major change, so this code really needs a lot more testing in various scenarios. Especially some Windows ACLs created in corporate environments are often a hard nut to crack, and the example from https://cygwin.com/ml/cygwin/2015-04/msg00513.html which was the ultimate downfall of the original implementation is the stuff which needs some good testing. There's, as usual, a downside: AuthZ leans a bit to the slow side. Cygwin caches information already gathered once on a per-process basis, but in locally crafted worst case scenarios (`ls' on lots of file owned by lots of different users and groups) the slowdown may be up to 25%. But that's really just a worst case, in the usual scenarios the slowdown should be mostly unnoticable. To alleviate the problem, the AuthZ code is fortunately only called for non-Cygwin ACLs and Cygwin ACLs created before this release. Within a pure Cygwin environment (e.g., some build directory only used with Cygwin tools) AuthZ should be practically unused. Apart from the aforementioned code changes to "just do it right", there are two additional changes I implemented for this new POSIX ACL revamp release: - I reverted the questionable change I added to 2.0.0-0.7 in terms of chmod group permission handling. The original description of this change was: If you have a non-trivial ACL with secondary accounts and thus a mask value, chmod is supposed to change only the mask, not the permissions of the primary group. However, if the primary group has few permissions to begin with, the result is really surprising. ls -l would, e.g., show read/write perms for the group, but the group might still have only read perms. Personally I find this chmod behaviour really, really bad, so I took the liberty to change it in a way which gives a much less surprising result: If you call chmod on a non-trivial ACL, the group permissions will be used for the primary group and the mask. - setfacl(1) now accepts the combination of the -b and -k options, just as on Linux. As for the description what this implementation strives for, please see http://linux.die.net/man/5/acl What's new: --- - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate standard Windows ACLs, the POSIX permissions of the owner and all other users in the ACL are computed using the Windows AuthZ API. This may slow down the computation of POSIX permissions noticably in some circumstances, but is generally more correct. The new code also ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux:
Re: Ability to specify /cygdrive mount value in setup
On Dec 6 15:28, Achim Gratz wrote: > Corinna Vinschen writes: > > No offense, but you didn't understand what I mean, it seems. > > I did, I think -- but read my request again. > > > Don't call cygpath. Just use /proc/cygdrive directly. It's that > > simple. While the cygdrive prefix changes, /proc/cygdrive will > > *never* change. E.g. > > I need cygpath to get the system directory (hint: it need not be in > C:\Windows\System32) and cygpath delivers that directory with the > cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all > those special directories would also be available via /proc/, > which means I wouldn't even need to fork cygpath for getting there. Does https://cygwin.com/ml/cygwin-announce/2015-12/msg5.html help? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDjVUZUks3P.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
On Dec 6 15:29, Achim Gratz wrote: > Corinna Vinschen writes: > >> VPN access with the worst possible terrestrial roundtrip has been tested > >> for the same case now and goes from 52s to ~1700s or a factor of 33. So > >> roundtrip delay adds an additional factor of about 3, but the server > >> response time seems to play the dominant role even in that scenario. > > > > Uhm... is that good or bad now?!? Do you still think adding this > > functionality is a good idea? > > For most of the things I did it worked OK, so I still think AuthZ should > be used. Ok, thanks a lot. I'm just wondering if I should really push this to stable state, given the fact that I won't be available starting next week until 2016-01-06. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprA2ar5qOin.pgp Description: PGP signature
Re: Ability to specify /cygdrive mount value in setup
Corinna Vinschen writes: >> I need cygpath to get the system directory (hint: it need not be in >> C:\Windows\System32) and cygpath delivers that directory with the >> cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all >> those special directories would also be available via /proc/, >> which means I wouldn't even need to fork cygpath for getting there. > > Does https://cygwin.com/ml/cygwin-announce/2015-12/msg5.html help? Thank you very much, that makes such things a lot easier. I'll release the new base-files when Cygwin 2.4.0 is officially out. 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 -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.4
Corinna Vinschen writes: > Ok, thanks a lot. I'm just wondering if I should really push this to > stable state, given the fact that I won't be available starting next > week until 2016-01-06. Well, that looks like it might be a common schedule for other folks as well, so you might just hold off until next year with the release. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8
2015-12-06 19:57 GMT+01:00 Corinna Vinschen : > Hi Cygwin friends and users, > > > I released a new TEST version of Cygwin, 2.4.0-0.8. > > This adds a new feature to cygpath, the -U flag, which allows to > generate /proc/cygdrive paths, which are unambiguous even if the > cygdrive prefix changes. E.g.: > > $ mount -p > Prefix Type Flags > /mntuser binmode > > $ cygpath -D > /mnt/c/Users/corinna/Desktop > > $ ./cygpath -DU > /proc/cygdrive/c/Users/corinna/Desktop > > I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7 > again since it's important that it gets tested: > > - Not a bug fix as such, but a workaround for new behaviour in Windows 10 > version 1511 64 bit. This version introduces a problem which existed in > a similar variation (just vice versa) in XP and Server 2003 64 bit as well. > An unexpected stack arrangement when starting a 64 bit Cygwin application > from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. > Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html > > > == > > Please, please, please test. > > If this code is acceptable, I will create an official 2.4.0 release > next week. > > == > > > This is the "new POSIX ACL handling reloaded" release. > > In local testing I successfully integrated AuthZ into the current Cygwin > code to generate more correct user permissions by being able to generate > effective permissions for arbitrary users. > > This success convinced me that it might be possible to pick up the POSIX > permission rewrite originally targeted for the 2.0.0 release and try to > update it using AuthZ and generally revamp it to reflect effective > permissions better. > > My local testing looks good, but this is a major change, so this code > really needs a lot more testing in various scenarios. Especially > some Windows ACLs created in corporate environments are often a hard > nut to crack, and the example from > > https://cygwin.com/ml/cygwin/2015-04/msg00513.html > > which was the ultimate downfall of the original implementation is > the stuff which needs some good testing. > > There's, as usual, a downside: AuthZ leans a bit to the slow side. > Cygwin caches information already gathered once on a per-process basis, > but in locally crafted worst case scenarios (`ls' on lots of file owned > by lots of different users and groups) the slowdown may be up to 25%. > But that's really just a worst case, in the usual scenarios the slowdown > should be mostly unnoticable. > > To alleviate the problem, the AuthZ code is fortunately only called for > non-Cygwin ACLs and Cygwin ACLs created before this release. Within a > pure Cygwin environment (e.g., some build directory only used with > Cygwin tools) AuthZ should be practically unused. > > Apart from the aforementioned code changes to "just do it right", there > are two additional changes I implemented for this new POSIX ACL revamp > release: > > - I reverted the questionable change I added to 2.0.0-0.7 in terms of > chmod group permission handling. The original description of this > change was: > > If you have a non-trivial ACL with secondary accounts and thus a > mask value, chmod is supposed to change only the mask, not the > permissions of the primary group. However, if the primary group has > few permissions to begin with, the result is really surprising. ls > -l would, e.g., show read/write perms for the group, but the group > might still have only read perms. > > Personally I find this chmod behaviour really, really bad, so I took > the liberty to change it in a way which gives a much less surprising > result: If you call chmod on a non-trivial ACL, the group > permissions will be used for the primary group and the mask. > > - setfacl(1) now accepts the combination of the -b and -k options, just as > on Linux. > > As for the description what this implementation strives for, please see > http://linux.die.net/man/5/acl > > > > What's new: > --- > > - New, unified implementation of POSIX permission and ACL handling. The > new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and > they allow to inherit the S_ISGID bit. ACL inheritance now really > works as desired, in a limited, but theoretically equivalent fashion > even for non-Cygwin processes. > > To accommodate standard Windows ACLs, the POSIX permissions of the > owner and all other users in the ACL are computed using the Windows > AuthZ API. This may slow down the computation of POSIX permissions > noticably in some circumstances, but is generally more correct. The > new code also ignores SYSTEM and Administrators group permissions when > computing the MASK
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.4.0-0.8
I forgot to say. I'm running Windows 10 1511 x64. 2015-12-06 21:21 GMT+01:00 Kacper Michajlow : > 2015-12-06 19:57 GMT+01:00 Corinna Vinschen : >> Hi Cygwin friends and users, >> >> >> I released a new TEST version of Cygwin, 2.4.0-0.8. >> >> This adds a new feature to cygpath, the -U flag, which allows to >> generate /proc/cygdrive paths, which are unambiguous even if the >> cygdrive prefix changes. E.g.: >> >> $ mount -p >> Prefix Type Flags >> /mntuser binmode >> >> $ cygpath -D >> /mnt/c/Users/corinna/Desktop >> >> $ ./cygpath -DU >> /proc/cygdrive/c/Users/corinna/Desktop >> >> I'd like to point out the Windows 10 1511 workaround added to 2.4.0-0.7 >> again since it's important that it gets tested: >> >> - Not a bug fix as such, but a workaround for new behaviour in Windows 10 >> version 1511 64 bit. This version introduces a problem which existed in >> a similar variation (just vice versa) in XP and Server 2003 64 bit as well. >> An unexpected stack arrangement when starting a 64 bit Cygwin application >> from a 32 bit application (e.g. 32 bit CMD.EXE) broke Cygwin's fork. >> Addresses: https://cygwin.com/ml/cygwin/2015-12/msg3.html >> >> >> == >> >> Please, please, please test. >> >> If this code is acceptable, I will create an official 2.4.0 release >> next week. >> >> == >> >> >> This is the "new POSIX ACL handling reloaded" release. >> >> In local testing I successfully integrated AuthZ into the current Cygwin >> code to generate more correct user permissions by being able to generate >> effective permissions for arbitrary users. >> >> This success convinced me that it might be possible to pick up the POSIX >> permission rewrite originally targeted for the 2.0.0 release and try to >> update it using AuthZ and generally revamp it to reflect effective >> permissions better. >> >> My local testing looks good, but this is a major change, so this code >> really needs a lot more testing in various scenarios. Especially >> some Windows ACLs created in corporate environments are often a hard >> nut to crack, and the example from >> >> https://cygwin.com/ml/cygwin/2015-04/msg00513.html >> >> which was the ultimate downfall of the original implementation is >> the stuff which needs some good testing. >> >> There's, as usual, a downside: AuthZ leans a bit to the slow side. >> Cygwin caches information already gathered once on a per-process basis, >> but in locally crafted worst case scenarios (`ls' on lots of file owned >> by lots of different users and groups) the slowdown may be up to 25%. >> But that's really just a worst case, in the usual scenarios the slowdown >> should be mostly unnoticable. >> >> To alleviate the problem, the AuthZ code is fortunately only called for >> non-Cygwin ACLs and Cygwin ACLs created before this release. Within a >> pure Cygwin environment (e.g., some build directory only used with >> Cygwin tools) AuthZ should be practically unused. >> >> Apart from the aforementioned code changes to "just do it right", there >> are two additional changes I implemented for this new POSIX ACL revamp >> release: >> >> - I reverted the questionable change I added to 2.0.0-0.7 in terms of >> chmod group permission handling. The original description of this >> change was: >> >> If you have a non-trivial ACL with secondary accounts and thus a >> mask value, chmod is supposed to change only the mask, not the >> permissions of the primary group. However, if the primary group has >> few permissions to begin with, the result is really surprising. ls >> -l would, e.g., show read/write perms for the group, but the group >> might still have only read perms. >> >> Personally I find this chmod behaviour really, really bad, so I took >> the liberty to change it in a way which gives a much less surprising >> result: If you call chmod on a non-trivial ACL, the group >> permissions will be used for the primary group and the mask. >> >> - setfacl(1) now accepts the combination of the -b and -k options, just as >> on Linux. >> >> As for the description what this implementation strives for, please see >> http://linux.die.net/man/5/acl >> >> >> >> What's new: >> --- >> >> - New, unified implementation of POSIX permission and ACL handling. The >> new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and >> they allow to inherit the S_ISGID bit. ACL inheritance now really >> works as desired, in a limited, but theoretically equivalent fashion >> even for non-Cygwin processes. >> >> To accommodate standard Windows ACLs, the POSIX permissions of the >> owner and all other users in the ACL are computed using the Windows >> AuthZ API. This may slow
Re: Cygwin multithreading performance
2015-12-06 9:02 GMT+01:00 Mark Geisert : > Kacper Michajlow wrote: >> >> 2015-12-05 23:40 GMT+01:00 Mark Geisert : >>> >>> It looks like we're going to have to compare actual pthread_mutex_lock() >>> implementations. Inspecting source is nice but I don't want to be >>> chasing a >>> mirage so I really hope there's a pthread_mutex_lock() function inside >>> the >>> MinGW git you are running. gdb could easily answer that question. Could >>> you please do an 'info func pthread_mutex_lock' after starting MinGW git >>> under MinGW gdb with a breakpoint at main() (so libraries are loaded). > > [...] >> >> Hmm, thinking about it mingw doesn't have pthread implementation or >> any wrapper for it. If someone needs pthread they would probably go >> for pthreads-w32 implementation. >> >> I started to wonder because I don't recall git would need pthreads to >> compile on Windows. And indeed they have a wrapper for Windows API... >> https://github.com/git/git/blob/master/compat/win32/pthread.h >> https://github.com/git/git/blob/master/compat/win32/pthread.c > > > OK, so git has its own pthread_mutex_lock/unlock ops which map to very > light-weight critical section operations. > >> Though it is not really a matter that "native" git build is fast and >> all, but that Cygwin's one really struggles if it comes to MT workload. > > > In the worst cases I see using your testcase, about half the time the > busiest locks are processed within 1 usec but there's a spectrum of longer > latencies for the other half of the time. I don't know (yet) if that can be > improved in Cygwin's more general implementation but at least the matter has > now been brought to our attention :). , Yes, I can imagine, git's objects are very small so threading overhead is very noticeable. >> And this not only issue with git unfortunately. Download speeds are >> also limited on Cygwin. I know POSIX compatibility layers comes with a >> price but I would love to see improvements in those areas. >> Cygwin: >> Receiving objects: 100% (230458/230458), 78.41 MiB | 1.53 MiB/s, done. >> "native" git: >> Receiving objects: 100% (230458/230458), 78.41 MiB | 18.54 MiB/s, done. > > > You're asserting this additional testcase has the same cause. What is > telling you that? And FTR what is the git command you are issuing? I can > then do the lock latency analysis on this new testcase if warranted. No, sorry, I mixed different things. It is just that I'm ruining both git build lately and I wanted to share another issue before I forget about it. This was git clone command for some random repository from github. There is a lot factors at hand here but the fact is with cygwin speed is capped on 1.5MB/s and this is reproducible. This is probably also related to the fact that git operates on large amount small object. But this time it is single thread workload. I tried strace this, but frankly I am not sure what to look for. All in all I just want to bring those issues to your attention. Whether it is fixable or not is another story. But we will not know unless someone with required knowledge analyze it. -Kacper -- 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
/etc/profile: avoid multiple /usr/bin in PATH
Hello, I set C:/cygwin/usr/bin in my windows-environment. Now /etc/profile always adds /usr/bin to PATH resulting in /usr/bin being twice in my cygwin-PATH. The attached patch fixes this. It also sets SHELL if not yet set and avoids a call of hostname. Maybe the maintainer takes a look. -Helmut -- profile.diff Description: Binary data -- 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
[ANNOUNCEMENT] Test: gmp-6.1.0-3p1
A test version of GMP is available that that re-instates a new feature of the previous 6.1.0-1 release: Speedup for Intel Broadwell and Skylake though assembly code making use of new ADX instructions. The previously reported problems with that code have been discussed with upstream and the test release contains an unreleased upstream patch that is supposed to fix it. Please test and report back on the main Cygwin mailing list. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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
