Re: Cygwin fork performance followup

On 2/4/2021 9:29 AM, Hamish McIntyre-Bhatty via Cygwin wrote: > Hi all, > > I managed to improve my Cygwin VM's performance significantly using a > variety of methods. > > If anyone else is experiencing troubles, seeing what I changed at >

Cygwin fork performance followup

Hi all, I managed to improve my Cygwin VM's performance significantly using a variety of methods. If anyone else is experiencing troubles, seeing what I changed at https://www.hamishmb.com/blog/improving-cygwins-performance-fork/ might also help you. Not using VirtualBox was the main improvement

Re: Optimising cygwin fork performance

On 16/12/2020 20:37, Brian Inglis wrote: > On 2020-12-16 10:36, Marco Atzeri via Cygwin-apps wrote: >> On 16.12.2020 13:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: >>> So I know it's been mentioned a lot that fork is slow on Cygwin, but >>> compared to other people's machines, eg when

Re: Optimising cygwin fork performance

On 2020-12-16 10:36, Marco Atzeri via Cygwin-apps wrote: On 16.12.2020 13:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: So I know it's been mentioned a lot that fork is slow on Cygwin, but compared to other people's machines, eg when building, it seems way slower for me. First I'd like to

Re: Optimising cygwin fork performance

Marco Atzeri via Cygwin-apps wrote: On 16.12.2020 13:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: Hi, So I know it's been mentioned a lot that fork is slow on Cygwin, but compared to other people's machines, eg when building, it seems way slower for me. First I'd like to know if there's

Re: Optimising cygwin fork performance

On 16.12.2020 13:13, Hamish McIntyre-Bhatty via Cygwin-apps wrote: Hi, So I know it's been mentioned a lot that fork is slow on Cygwin, but compared to other people's machines, eg when building, it seems way slower for me. First I'd like to know if there's a good way to measure this that

Optimising cygwin fork performance

Hi, So I know it's been mentioned a lot that fork is slow on Cygwin, but compared to other people's machines, eg when building, it seems way slower for me. First I'd like to know if there's a good way to measure this that anyone has found, because I'm not sure how to measure it. If I print

[newlib-cygwin] Cygwin: fork: attach child not before success

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=2986a524d853ab6d06bf88b65e0e9d60cea51dcc commit 2986a524d853ab6d06bf88b65e0e9d60cea51dcc Author: Michael Haubenwallner Date: Wed Jul 31 12:35:33 2019 +0200 Cygwin: fork: attach child not before success Do not attach

[PATCH v2 2/2] Cygwin: fork: attach child not before success

Do not attach to the child before it was successfully initialized, or we would need more sophisticated cleanup on child initialization failure, like suppressing SIGCHILD delivery with multiple threads ("waitproc") involved. Improves "Cygwin: fork: Remember child not before su

[PATCH 2/2] Cygwin: fork: Attach child not before success.

Do not attach to the child before it was successfully initialized, or we would need more sophisticated cleanup on child initialization failure, like suppressing SIGCHILD delivery with multiple threads ("waitproc") involved. Improves "Cygwin: fork: Remember child not before su

[newlib-cygwin] Revert "Cygwin: fork: Remember child not before success."

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=000f2409b118e85daaa7064b5375245b8f48ab27 commit 000f2409b118e85daaa7064b5375245b8f48ab27 Author: Ken Brown Date: Tue Jun 11 08:11:01 2019 -0400 Revert "Cygwin: fork: Remember child not before success." Th

Re: [PATCH 1/2] Cygwin: fork: Always pause child after fixups.

On Apr 30 09:09, Michael Haubenwallner wrote: > Pause the child process after performing fork fixups even if there were > no dynamically loaded dlls with extra data/bss transfers to wait for. > This allows the parent process to cancel the current fork call even if > the child process was

[newlib-cygwin] Cygwin: fork: Remember child not before success.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=f03ea8e1c57bd5cea83f6cd47fa02870bdfeb1c5 commit f03ea8e1c57bd5cea83f6cd47fa02870bdfeb1c5 Author: Michael Haubenwallner Date: Thu May 2 12:12:44 2019 +0200 Cygwin: fork: Remember child not before success. Do not remember

[newlib-cygwin] Cygwin: fork: Always pause child after fixups.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a8c23e4423ebb3458db93341d8a9bc73b0a04b03 commit a8c23e4423ebb3458db93341d8a9bc73b0a04b03 Author: Michael Haubenwallner Date: Tue Apr 30 09:09:13 2019 +0200 Cygwin: fork: Always pause child after fixups. Pause the child

Re: [PATCH 2/2] Cygwin: fork: Remember child not before success.

admitted I didn't perform the full >24h build. Patch updated. Thanks! /haubi/ >From 69c21e8e5d19cc6ec205a4e44d6b84542b1fef98 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Mon, 29 Apr 2019 16:03:51 +0200 Subject: [PATCH] Cygwin: fork: Remember child not before success. Do not remember t

Re: [PATCH 2/2] Cygwin: fork: Remember child not before success.

Hi Michael, On Apr 30 09:09, Michael Haubenwallner wrote: > Do not remember the child before it was successfully initialized, or we > would need more sophisticated cleanup on child initialization failure, > like cleaning up the process table and suppressing SIGCHILD delivery > with multiple

[PATCH 1/2] Cygwin: fork: Always pause child after fixups.

Pause the child process after performing fork fixups even if there were no dynamically loaded dlls with extra data/bss transfers to wait for. This allows the parent process to cancel the current fork call even if the child process was successfully initialized already. This is a preparation for

[PATCH 2/2] Cygwin: fork: Remember child not before success.

Do not remember the child before it was successfully initialized, or we would need more sophisticated cleanup on child initialization failure, like cleaning up the process table and suppressing SIGCHILD delivery with multiple threads ("waitproc") involved. --- winsup/cygwin/fork.cc | 33

Re: [PATCH] Cygwin: fork: remember child as late as possible

On Apr 12 15:31, Michael Haubenwallner wrote: > Otherwise, when the child does fail to reload dlls and terminates, we > produce a SIGCHILD signal, even if we did not succeed in starting up the > child process at all. Also, we would need to reap that child somewhere. I'm not that happy with the

[PATCH] Cygwin: fork: remember child as late as possible

Otherwise, when the child does fail to reload dlls and terminates, we produce a SIGCHILD signal, even if we did not succeed in starting up the child process at all. Also, we would need to reap that child somewhere. --- winsup/cygwin/fork.cc | 71 --- 1

[newlib-cygwin] Cygwin: fork: reserve dynloaded dll areas earlier

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=023c107a22ebd2f540fa3f4888535aad32839fe2 commit 023c107a22ebd2f540fa3f4888535aad32839fe2 Author: Michael Haubenwallner Date: Tue Mar 26 17:38:36 2019 +0100 Cygwin: fork: reserve dynloaded dll areas earlier In dll_crt0_0

[newlib-cygwin] Cygwin: fork/exec: Allow all users PROCESS_QUERY_LIMITED_INFORMATION

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=24f9cb015ea011b43f9c4b865c98b61be731487f commit 24f9cb015ea011b43f9c4b865c98b61be731487f Author: Corinna Vinschen Date: Tue Mar 12 11:41:35 2019 +0100 Cygwin: fork/exec: Allow all users PROCESS_QUERY_LIMITED_INFORMATION

[newlib-cygwin] Cygwin: fork: fix child process permissions, take 3

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=38dde5f4c4c2e33dfe6dfb9d1bc593d13d85a290 commit 38dde5f4c4c2e33dfe6dfb9d1bc593d13d85a290 Author: Corinna Vinschen Date: Sun Mar 3 10:59:13 2019 +0100 Cygwin: fork: fix child process permissions, take 3 Per MSDN

[newlib-cygwin] Cygwin: fork: add PROCESS_VM_OPERATION to child process permissions

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7e671e7578c9ab8a1144a10c1187b7ced984 commit 7e671e7578c9ab8a1144a10c1187b7ced984 Author: Corinna Vinschen Date: Sun Feb 17 22:51:21 2019 +0100 Cygwin: fork: add PROCESS_VM_OPERATION to child process permissions

[newlib-cygwin] Cygwin: fork: terminate child process unconditionally in error case

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7225a82c1a4e90bcea2a17da12a427d1e783de30 commit 7225a82c1a4e90bcea2a17da12a427d1e783de30 Author: Corinna Vinschen Date: Tue Feb 5 12:52:13 2019 +0100 Cygwin: fork: terminate child process unconditionally in error case

[newlib-cygwin] fork: remove cygpid.N sharedmem on fork failure

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fb3e8bd88b06be6b5e748b99aa50968bb46653a1 commit fb3e8bd88b06be6b5e748b99aa50968bb46653a1 Author: Michael Haubenwallner Date: Tue Jun 5 12:40:21 2018 +0200 fork: remove cygpid.N sharedmem on fork failure When fork finally

[newlib-cygwin] Cygwin: fork: fix child process permissions, take 2

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ef8ce3077f55d5a105b39f605b877da50ab80aa7 commit ef8ce3077f55d5a105b39f605b877da50ab80aa7 Author: Corinna Vinschen Date: Wed Jan 30 12:18:03 2019 +0100 Cygwin: fork: fix child process permissions, take 2 VirtualQueryEx

[newlib-cygwin] Cygwin: fork/exec: fix child process permissions

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5a0f2c00aa019de73a6077ca3017b594c43184a4 commit 5a0f2c00aa019de73a6077ca3017b594c43184a4 Author: Corinna Vinschen Date: Tue Jan 29 16:26:45 2019 +0100 Cygwin: fork/exec: fix child process permissions - Exec'ed/spawned

[newlib-cygwin] Cygwin: fork: restrict parent handle perms and drop handle after use

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=69cc7a068656b5c6ef07ca079a213f801e02e650 commit 69cc7a068656b5c6ef07ca079a213f801e02e650 Author: Corinna Vinschen Date: Sun Jan 27 13:15:15 2019 +0100 Cygwin: fork: restrict parent handle perms and drop handle after use

[newlib-cygwin] fork: Don't copy _main_tls->local_clib from *_impure_ptr

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=48755fb9bca8ae379a6f96619b8b7774ff4b4494 commit 48755fb9bca8ae379a6f96619b8b7774ff4b4494 Author: Corinna Vinschen Date: Fri Mar 10 20:44:53 2017 +0100 fork: Don't copy _main_tls->local_clib from *_impure_ptr

Re: Cygwin fork problem: abort: can't commit memory for stack

Hi, As suggested by Marco, I stripped the PATH to bare minimum and then it started building. But slowly  slowly, one at a time, I started adding more paths to path variable and finally I have restored it back to old one but its now building without any problem. So, I am not sure what happened.

Re: Cygwin fork problem: abort: can't commit memory for stack

On 03/12/2012 5:23 AM, Techie Help wrote: Hi, As suggested by Marco, I stripped the PATH to bare minimum and then it started building. But slowly slowly, one at a time, I started adding more paths to path variable and finally I have restored it back to old one but its now building without

Re: Cygwin fork problem: abort: can't commit memory for stack

On 11/30/2012 5:24 PM, Techie Help wrote: I have set up a new PC and installed cygwin on it. Its windows 7 pro. Whenever I try to build our application on it, I get the following error: 0 [main] sh 3472 child_info_fork::abort: can't commit memory for stack 0x28A000(90112), Win32 error 487

Re: Cygwin fork problem: abort: can't commit memory for stack

On Sat, Dec 01, 2012 at 09:32:38AM +0100, marco atzeri wrote: On 11/30/2012 5:24 PM, Techie Help wrote: I have set up a new PC and installed cygwin on it. Its windows 7 pro. Whenever I try to build our application on it, I get the following error: 0 [main] sh 3472 child_info_fork::abort:

Re: Cygwin fork problem: abort: can't commit memory for stack

Very same problem, already discussed in another thead or two. I will also be grateful if this could be fixed. Massi 2012/11/30 Techie Help techiei...@yahoo.co.uk: I have set up a new PC and installed cygwin on it. Its windows 7 pro. Whenever I try to build our application on it, I get the

Re: Typical Cygwin fork problem

On 2011-09-06 01:53Z, jan.kolar wrote: Why the newest version rebase/rebase-3.0-2 utilities for rebasing DLLs [...] is listed in the middle of this page? Actually, the one at the bottom is the newest: 2009 April rebase-3.0-2 2009 July rebase-3.0.1-1 Anything following a '-' at

Re: Typical Cygwin fork problem

On Mon, Sep 05, 2011 at 06:53:34PM -0700, jan.kolar wrote: Then you need to install the rebase package: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=rebaseall Why the newest version rebase/rebase-3.0-2 utilities for rebasing DLLs to load at alternate addresses is listed in the

Re: Typical Cygwin fork problem

all seems to be sorted (it almost is). -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32404960.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http

Re: Typical Cygwin fork problem

On Sat, Aug 20, 2011 at 05:03:16AM -0700, big glass wrote: $ /bin/peflagsall/ /usr/bin/ash: Can't open /bin/peflagsall/ :( Why are you putting slashes on the end of the command? You wouldn't do that on Windows or Linux. -- Problem reports: http://cygwin.com/problems.html FAQ:

Re: Typical Cygwin fork problem

: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32300380.html Sent from the Cygwin list mailing list

Re: Typical Cygwin fork problem

/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32300438.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http

Re: Typical Cygwin fork problem

On Aug 20 01:43, big glass wrote: thx, im now getting this: $/bin/rebaseall /usr/bin/ash: $: not found $ Sigh. The $ is the universal sign for the shell prompt. It's the default shell prompt on Unix machines. You are not supposed to type it in. Just start ash, then you'll see the

Re: Typical Cygwin fork problem

mate -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32300974.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation

Re: Typical Cygwin fork problem

$ /bin/peflagsall/ /usr/bin/ash: Can't open /bin/peflagsall/ :( $ ./reply-to-typical-fork-complaint.sh Please run rebaseall (and peflagsall+reboot if on Vista or Win7) -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32301099.html Sent from

Typical Cygwin fork problem

) 00289388 6102796B (6117EC60, 8000, , 61180977) 0028A3B8 61004F1B (611A7FAC, 612492D4, 003E, 003F) End of stack trace 1 [main] ruby 9668 fork: child 7216 - died waiting for dll loading, errno -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork

Re: Typical Cygwin fork problem

On 19/08/2011 5:23 AM, big glass wrote: I have ruby installed and am trying this, but run this but lots of errors: $ gem install sproutcore Fetching: rack-1.3.2.gem (100%) Fetching: json_pure-1.4.6.gem (100%) Fetching: extlib-0.9.15.gem (100%) Fetching: erubis-2.7.0.gem (100%) Fetching:

Re: Typical Cygwin fork problem

cheers, tried it in ash but get this: $ rebaseall : not found $ sr/bin/ash: rebaseall: not found -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32295811.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports

Re: Typical Cygwin fork problem

On Fri, Aug 19, 2011 at 4:35 PM, big glass wrote: cheers, tried it in ash but get this: $ rebaseall   : not found $ sr/bin/ash: rebaseall: not found Then you need to install the rebase package: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=rebaseall Csaba -- GCS a+ e++ d- C++ ULS$ L+$

Re: Typical Cygwin fork problem

On Aug 19 07:35, big glass wrote: cheers, tried it in ash but get this: $ rebaseall : not found $ /bin/rebaseall Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports:

Re: Typical Cygwin fork problem

:) it already is installed, ask wont recognise it :) -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32296617.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ

Re: Typical Cygwin fork problem

On Fri, Aug 19, 2011 at 09:13:13AM -0700, big glass wrote: it already is installed, ask wont recognise it :) It's probably wearing glasses then. Duh. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation:

Re: Typical Cygwin fork problem

On Aug 19 09:13, big glass wrote: :) it already is installed, ask wont recognise it :) $ /bin/rebaseall--- use the full path Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat --

Re: Typical Cygwin fork problem

this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32296836.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http

Re: Typical Cygwin fork problem

On 8/19/2011 11:38, big glass wrote: so what is ash exactly?? ash is another name for dash, which is described here: http://en.wikipedia.org/wiki/Debian_Almquist_shell The short answer is that it's a minimal shell that you need to use in your case for running the rebaseall command so that

Re: Typical Cygwin fork problem

On 08/19/2011 10:38 AM, big glass wrote: so what is ash exactly?? Another name for dash, which is a lighter-weight shell than bash. In particular, since dash pulls in fewer shared libraries, it can rebase things that bash cannot. -- Eric Blake ebl...@redhat.com+1-801-349-2682

Re: Typical Cygwin fork problem

i am noob, but prof windows programmer 3+ years :) how can i make sure that you exit all Cygwin processes what is rebasing? -- View this message in context: http://old.nabble.com/Typical-Cygwin-fork-problem-tp32293766p32297033.html Sent from the Cygwin list mailing list archive at Nabble.com

Re: Typical Cygwin fork problem

On Fri, Aug 19, 2011 at 7:07 PM, big glass wrote: how can i make sure that you exit all Cygwin processes Get Process Explorer from sysinternals (now Microsoft: http://technet.microsoft.com/en-us/sysinternals/bb896653). It allows you to search for in-use files and handles. If cygwin1.dll is

GNU pth + cygwin + fork [Was: Re: fork failure?]

Charles Wilson wrote: Ach, the purist in me just wants to get pth working... Hmm...it appears the right way to do this is NOT to add another special case in pth: no, on cygwin THIS is the way you poke around in the jmp_buf + extra cygwin TLC in pth_fork(). Instead, cygwin pth should use the

Re: GNU pth + cygwin + fork [Was: Re: fork failure?]

Charles Wilson wrote: In the short-to-medium term, it looks like converting libassuan and gnupg to use pthreads instead of pth won't be terribly difficult. Once once sig[alt]stack is available I can modify cygwin-pth to use the sig[alt]stack Machine Context Implementation instead of the

Re: GNU pth + cygwin + fork [Was: Re: fork failure?]

Dave Korn wrote: My first thought would be to figure out what pth is attempting to do while messing in jmp_buf, and make it work. It's bad, unmaintainable code, that will break again in the future if ever jmp_buf is rearranged - but it only has to stagger along for another couple of months

cygwin/fork slowness due to UNCs in PATH

Just a quick comment.  I've been a long user of cygwin, and until recently noticed that cygwin was running extremely slow (it would take several seconds to fork off a command).  After debugging a while, it turns out that I had added UNC (\\ style windows) paths to my system PATH environment

RE: cygwin/fork slowness due to UNCs in PATH

On 01 February 2007 16:54, Song, Conrad W wrote: it turns out that I had added UNC (\\ style windows) paths to my system PATH environment variable.  The removal of these (maybe slow network drives) from the PATH (or disconnection from the network) solved the problem for me.  Perhaps further

cygwin fork()

Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? While building projects using libtool (which using heavy sh, hence fork() calls) I regularly have to fire off 'make -j16's just to get around waiting ages when using a single make job. -cl

RE: cygwin fork()

On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? Some reason == lack of O/S support. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info

Re: cygwin fork()

On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? Some reason == lack of O/S support. Yes I can understand that. I'm assuming there is some CreateProcess() magic happening behind

RE: cygwin fork()

On 01 September 2006 11:22, [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? Some reason == lack of O/S support. Yes I can understand that. I'm assuming

Re: cygwin fork()

On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? Some reason == lack of O/S support. Basically, this is what I'm talking

Re: cygwin fork()

On Fri, 1 Sep 2006, clayne wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? While building projects using libtool (which using heavy sh, hence fork() calls) I regularly have to fire off 'make -j16's just to get around waiting ages when

Re: cygwin fork()

On Fri, 1 Sep 2006, clayne wrote: On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? Some reason == lack of O/S support

Re: cygwin fork()

On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: While Cygwin is an *emulation* layer, and emulation is inherently slower than straight execution, there are other potential reasons for the slowness. Check your anti-virus and firewall software settings. If possible, exclude

Re: cygwin fork()

On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: 1157123322 + echo blah1 1157123322 blah1 3 seconds of doing absolutely nothing here 1157123325 + test -z '' 1157123325 + echo blah2 1157123325 blah2 I just also copied the same libtool to 3 different hard drives, one even

Re: cygwin fork()

On Fri, Sep 01, 2006 at 09:09:11AM -0700, [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote: It's definitely none of those as I don't run any firewall or antivirus software whatsoever on this box. Windows 2003 Server, minimal set of services. The

Re: cygwin fork()

On Fri, 1 Sep 2006, Christopher Faylor wrote: On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: While Cygwin is an *emulation* layer, and emulation is inherently slower than straight execution, there are other

Re: cygwin fork()

On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote: BTW: I started up filemon to watch what was going on from it's standpoint, and it shows a huge number of READs on libtool, all SUCCESS, but the offset is always 1 higher than previous, with a length of 1. Like it's literally

Re: cygwin fork()

On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: I've since removed the setmode() calls within a bash build and am testing now. UPDATE: SOLVED. Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on reading the rest of the bash script (which I

Re: cygwin fork()

On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote: BTW: I started up filemon to watch what was going on from it's standpoint, and it shows a huge number of READs on libtool, all SUCCESS, but the offset is

Re: cygwin fork()

On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote: In regards to setting the fd to textmode as a way of stripping CRs. Only problem is that it's making 213,110 syscalls for a 213k libtool script. That cannot be an efficient way to remove CRs from input. Opening a file with

bash problems ? (was Re: cygwin fork())

I'm just changing the subject so that Eric will, with luck, notice and comment on what's going on here. cgf On Fri, Sep 01, 2006 at 10:47:13AM -0700, [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote: In regards to setting the fd to textmode as a way of

RE: cygwin fork()

On 01 September 2006 18:47, [EMAIL PROTECTED] wrote: I found the real culprit, which I had also ifdef'd out because it looked bogus and crufty: /* Return 1 if a seek on FD will succeed. */ #ifndef __CYGWIN__ # define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) = 0) #else # define

Re: cygwin fork()

On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote: On 01 September 2006 18:47, [EMAIL PROTECTED] wrote: I found the real culprit, which I had also ifdef'd out because it looked bogus and crufty: /* Return 1 if a seek on FD will succeed. */ #ifndef __CYGWIN__ # define fd_is_seekable(fd)

RE: cygwin fork()

From: Christopher Faylor Sent: Friday, September 01, 2006 1:01 PM Subject: Re: cygwin fork() On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote: On 01 September 2006 18:47, clayne wrote: I found the real culprit, which I had also ifdef'd out because it looked bogus and crufty

Re: cygwin fork()

Gary R. Van Sickle wrote: AFAIK, Cygwin's lseek should handle seeking on text streams. DJ implemented that years ago. Last I looked, which was admittedly also years ago, it was #if 0'ed out, with a comment to the effect of Nobody has any business seeking around in text files. FWIW,

Re: cygwin fork()

Brian Dessent wrote: Gary R. Van Sickle wrote: AFAIK, Cygwin's lseek should handle seeking on text streams. DJ implemented that years ago. Last I looked, which was admittedly also years ago, it was #if 0'ed out, with a comment to the effect of Nobody has any business seeking around in text

Re: cygwin fork()

On Fri, Sep 01, 2006 at 05:07:49PM -0500, Gary R. Van Sickle wrote: From: Christopher Faylor Sent: Friday, September 01, 2006 1:01 PM Subject: Re: cygwin fork() On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote: On 01 September 2006 18:47, clayne wrote: I found the real culprit

Re: cygwin fork()

But Cygwin's should work fine, and if it means saving a bazillion 1-byte syscalls then I think bash should be patched to remove this sillyness ASAP. I get the hint! Look for a new release of bash in the near future; and once I get the cygport build going, I will also try to get the bash-3.2

Re: cygwin fork problem maybe?

Brian Dessent wrote: Linda W wrote: Windows just doesn't support forking at all, as far as I know. activeperl emulates forking using win32 threads. I don'tknow how cygwin handles it, but my guess is that it's not very well :-( This smells like total FUD. This person that

Re: cygwin fork problem maybe?

On Tue, Jun 06, 2006 at 01:30:43PM -0700, Linda W wrote: A problem I reported in trying to install File::BOM (module to handle files with Unicode Byte-Order-Marks) under CPAN originally here: http://sourceware.org/ml/cygwin/2006-02/msg00238.html last February is still a problem. I bounced it

cygwin fork problem maybe?

A problem I reported in trying to install File::BOM (module to handle files with Unicode Byte-Order-Marks) under CPAN originally here: http://sourceware.org/ml/cygwin/2006-02/msg00238.html last February is still a problem. I bounced it off of the module maintainer, and he believes the problem

Re: cygwin fork problem maybe?

Linda W wrote: Windows just doesn't support forking at all, as far as I know. activeperl emulates forking using win32 threads. I don'tknow how cygwin handles it, but my guess is that it's not very well :-( This smells like total FUD. This person that admittedly does not use Cygwin nor

Cygwin fork implementation

Hi, In Cygwin fork code the statement int res = setjmp (grouped.ch.jmp); if (res) res = fork_child (grouped.ch.parent, grouped.first_dll, grouped.load_dlls); else res = fork_parent (grouped.ch.parent, grouped.first_dll, grouped.load_dlls, esp, grouped.ch); avoids the fork being

Re: Cygwin fork implementation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sudhahar on 2/6/2006 5:33 AM: Hi, In Cygwin fork code the statement int res = setjmp (grouped.ch.jmp); if (res) res = fork_child (grouped.ch.parent, grouped.first_dll, grouped.load_dlls); else res = fork_parent

Re: Cygwin fork failure

Larry Hall (Cygwin) wrote: [EMAIL PROTECTED] wrote: On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote: David Svoboda wrote: I have built a C++ server program called 'analyzer'. But when I try to run it, it fails upon trying to execute a 'fork' command. Why? snip If

Re: Cygwin fork failure

On 11/23/2005, David Svoboda wrote: My best guess is that this bug was introduced by a new version of cygwin, as it did not occur until I did a cygwin-update. But didn't you claim that switching back to an older version of Cygwin didn't help? It seems that the oldest cygwin I can get is

Re: Cygwin fork failure

[EMAIL PROTECTED] wrote: On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote: David Svoboda wrote: I have built a C++ server program called 'analyzer'. But when I try to run it, it fails upon trying to execute a 'fork' command. Why? snip If running 'rebaseall' doesn't

Re: Cygwin fork failure

On Saturday 19 November 2005 01:07 am, Larry Hall (Cygwin) wrote: David Svoboda wrote: I have built a C++ server program called 'analyzer'. But when I try to run it, it fails upon trying to execute a 'fork' command. Why? $ analyzer --KANTOO_LANGUAGE=toy -server-multiple -fork

Cygwin fork failure

I have built a C++ server program called 'analyzer'. But when I try to run it, it fails upon trying to execute a 'fork' command. Why? $ analyzer --KANTOO_LANGUAGE=toy -server-multiple -fork Analyzer 2.0 *** 5 [main] analyzer 1712 fhandler_disk_file::fixup_mmap_after_fork: requested

Re: Cygwin fork failure

David Svoboda wrote: I have built a C++ server program called 'analyzer'. But when I try to run it, it fails upon trying to execute a 'fork' command. Why? $ analyzer --KANTOO_LANGUAGE=toy -server-multiple -fork Analyzer 2.0 *** 5 [main] analyzer 1712

Re: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

Hi, I've ended up here after having rounded the gcc-irc-channel and the crosscompiler mailing-list. The story: I have compiled a gcc crosscompiler hosted under Cygwin using Dan Kegel's Crosstool scripts. However, as my application is growing in size (number of .o files) I suddenly get the

RE: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

Original Message From: Martin Egholm Nielsen Sent: 03 March 2005 08:42 However, as my application is growing in size (number of .o files) I suddenly get the following fault message from collect2.exe when trying to link them all together: $ powerpc-405-linux-gnu-gcj --main=foo.Main

Re: Error linking under Cygwin: fork: can't reserve memory for stack XXX, Win32 error 487

Hi, However, as my application is growing in size (number of .o files) I suddenly get the following fault message from collect2.exe when trying to link them all together: $ powerpc-405-linux-gnu-gcj --main=foo.Main *.o

  1   2   >