Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]

2021-09-07 Thread Peter Dons Tychsen
Hi Ken, On Mon, 2021-09-06 at 17:24 -0400, Ken Brown via Cygwin wrote: > You're looking at the wrong source code.  The bug didn't occur until > the code > was changed to do the following: You are right. I do not know why i looked at an old checkout of the code. Shame on me! Sorry for wasting

Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]

2021-09-06 Thread Peter Dons Tychsen
Hi there, On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote: > > No, wait.  I get what you say.  The optimzation settings of the test > > case should have no influence on the code inside the DLL.  That > > doesn't > > make sense for sure.  However, I ran the testcase under GDB, I

Re: mmap failure [was: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?]

2021-09-06 Thread Peter Dons Tychsen via Cygwin
Hi there, On Mon, 2021-09-06 at 14:40 -0400, Ken Brown via Cygwin wrote: > > No, wait.  I get what you say.  The optimzation settings of the test > > case should have no influence on the code inside the DLL.  That > > doesn't > > make sense for sure.  However, I ran the testcase under GDB, I

Re: Synchronization problem with posix_spawn

2020-08-21 Thread Peter Dons Tychsen via Cygwin
Hi Corinna, On Thu, 2020-08-20 at 14:50 +0200, Corinna Vinschen wrote: > No, it won't work as expected, as you can see from the discussion in > > this thread. Some internal work would be required. OK. So even with no file actions and spawn atributes, it still would break things. What kind of

Re: Synchronization problem with posix_spawn

2020-08-19 Thread Peter Dons Tychsen via Cygwin
Hi Corinna, > spawn alone doesn't cut it, due to the requirement to support the > additional file actions and spawn atributes POSIX defines. This > would require a revamp of Cygwin's spawn functionality, which is > already quite complicated. So this is something I'm only willing > to do in

Re: Synchronization problem with posix_spawn

2020-08-03 Thread Peter Dons Tychsen via Cygwin
Hi all, On Fri, 2020-07-31 at 10:10 +0200, Corinna Vinschen wrote: > Oh well. I did a quick test with your new testcase (thanks for > that!) > and it seems to be a bit more complicated than I anticipated > yesterday. > The parent-child relationship between the processes is broken. I > have > to

Re: calm bounces (was: Undelivered Mail Returned to Sender)

2020-04-16 Thread Peter Dons Tychsen via Cygwin
On Thu, 2020-04-16 at 08:35 -0600, Brian Inglis wrote: > On 2020-04-15 04:44, Mail Delivery System via Cygwin wrote: > > This is the mail system at host sourceware.org. > > I'm sorry to have to inform you that your message could not > > be delivered to one or more recipients. It's attached below.

Re: Use cygwin to run autotools for MSVC?

2020-03-27 Thread Peter Dons Tychsen via Cygwin
Hi Mike, > Is it possible use Cygwin to run an autotools 'configure' script but > have the compiler be MSVC? Yeah, sure, i have done this in the past. "./configure CC=cl.exe" should get you going as far as i remember. Make sure your MS tools are in your PATH. There are limitations though, as

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-13 Thread Peter Dons Tychsen
Hi Takashi, On Thu, 2020-02-13 at 13:13 +0900, Takashi Yano wrote: > Could you please try latest snapshot? > https://cygwin.com/snapshots/ The commit regarding use of kill() does the trick. It's a go from here :-). Thanks for all the help, /pedro -- Problem reports:

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-11 Thread Peter Dons Tychsen
Hi Takashi, Thanks for your effort. On Tue, 2020-02-11 at 22:16 +0900, Takashi Yano wrote: > however, I found the real cause is that errno is accidentally set > by kill() in pty system calls. That is, the problem is not in the > kill() itself but in usage of it. Cygwin older than 3.1.0 does not

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-11 Thread Peter Dons Tychsen
On Tue, 2020-02-11 at 11:38 +0100, Peter Dons Tychsen wrote: > processes. And why did this work before? And why does it work when running without minnty? How does that play into this? Thanks, /pedro -- Problem reports: http://cygwin.com/problems.html FAQ: h

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-11 Thread Peter Dons Tychsen
Hi Takashi, Thanks for looking at this & your great work on Cygwin! On Tue, 2020-02-11 at 11:20 +0900, Takashi Yano wrote: > Is this the same as your problem? Yeah, it could be. Could this result in fork error messages as we are seeing all over the place? > If so, it goes without stopping 1

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-10 Thread Peter Dons Tychsen
Hi all, On Thu, 2020-02-06 at 09:18 +1100, David Finnie wrote: > That would be awesome if you could create a small test case OK, i put together a test-case: 1) Put attached makefile somewhere 2) Download https://nuwen.net/files/mingw/mingw-17.1-without-git.exe and unzip it in same place. 3) Now

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-02-05 Thread Peter Dons Tychsen
Hi David & Co, > I have started down the road of building cygwin, but did run into a > few issues so don't have a debuggable version yet. If you beat me to > it, please let me know. Thanks! Any findings? I have found something interesting: 1) If i run the terminal without mintty, the problem

Re: fork: Resource temporarily unavailable errors after upgrading cygwin packages

2020-01-02 Thread Peter Dons Tychsen
Hi Cygwinners, On Thu, 2020-01-02 at 10:43 +1100, David Finnie wrote: > I did as Ken suggested and reverted to 3.0.7-1. (Thanks, Ken !) > > That has fixed the issue for me, and the make it now running again > at > full speed. I forgot to mention that it did seem somewhat slower > with > the

Re: Who shot the snaps ? (snapshots are no longer built).

2019-10-23 Thread Peter Dons Tychsen via cygwin
On Wed, 2019-10-23 at 10:18 +0200, Peter Dons Tychsen wrote: > OK thanks, > > I will keep an eye out for them :-) > > Thanks, > > /pedro And sorry for the top post. I have just now slapped myself as punishment :-). /pedro -- Problem reports: http://cygwin.

Re: Who shot the snaps ? (snapshots are no longer built).

2019-10-23 Thread Peter Dons Tychsen via cygwin
OK thanks, I will keep an eye out for them :-) Thanks, /pedro On Tue, 2019-10-22 at 19:40 +0200, Corinna Vinschen wrote: > On Oct 22 19:11, donpedro.tdcadsl.dk via cygwin wrote: > > Hello all. > > > > There does not appear to be any snaps any more at: > > https://cygwin.com/snapshots/ > >

Re: execvp* and spawnvp* react differently to same PATH environment variable

2019-10-09 Thread Peter Dons Tychsen via cygwin
Hi Ken, > I think you're probably right. The use of FE_NNF in execvp* was > introduced in > commit 6d63272b. I suspect it was just an oversight that the spawvp* > functions > weren't changed in the same way. I'll send a patch to the cygwin- > patches list > to fix this. When Corinna

Re: mingw64-x86_64-wxWidgets3.0 and mingw64-i686-wxWidgets3.0 needs repository rebuild.

2016-12-13 Thread Peter Dons Tychsen
Hello Yaakov & co. Are there plans to update these any time soon? I could fear that other mingw packages (at least the c++ ones) suffer the same problem currently. On another note, thanks Yaakov for maintaining so many mingw packes all together. I really appreciate it. I makes windows

Fw: 1.5.11 bug in WEXITSTATUS() macro (wait.h)

2004-09-25 Thread Peter Dons Tychsen
Hello. The WEXITSTATUS is a bit buggy. (wait.h) The macro extracts information gained from a call to waitpid() (and others). The information it extracts is the status of the completed process (8 bit signed value). The problem is that the macro does not cast the value to a signed integer (like