spawn() vs fork() in cross compiler on cygwin

Christopher Faylor cygwin@cygwin.com
Wed Nov 13 09:41:00 GMT 2002


Please check out the project web page for links to available information
and ports:  http://cygwin.com/ .

If you don't see what you need there, then the cygwin mailing list is
the best place to make observations or get questions answered.
Information on the mailing list is available at the project web page.

For your convenience, I've reset the Reply-To: address to point to the
cygwin mailing list.  I've also Cc'ed this reply there.

On Wed, Nov 13, 2002 at 12:20:02PM -0500, Ken Faiczak wrote:
>I only came upon this since trying to get gcc 3.2 working has been
>problematic
>we have been using gcc 3.0.3 for on cygwin for the last year and it was
>built with
>fork() (cross compiler for mips) and came across some info on the cygwin
>site
>stating that there is ~20% boost from spawn over fork, now that might be
>pretty 
>old and outdated, but...
>
>I have tried debugging the issue with fork, trying to get an strace,
>but strace seems to affect its behaviour making it slower or whatever
>so it does not seem to happen.
>updated to the latest cygwin etc, windows patches etc.
>
>basically using Win2000 SP3 cygwin 1.3.14-1
>Its a dual P3x700 256MB.
>everything running out of clearcase which causes some delays in the system.
>
>The only thing I change is the new compiler and I get
>ccmips: fork: Permission denied
>
>basically its a build tree that takes ~1.5 hours to compile 
>and this will happen almost guaranteed somewhere about halfway through
>and once it starts happening it becomes fairly regular but 
>
>it happens more often when the system is heavily loaded, ie running make
>multiple
>times simultaneously in different trees, and seems to happen more often over
>time
>ie. after a reboot it rarely happens (so its probably a Windows issue)
>
>I don't think its out of memeory when this happens, I don't get a
>virtual memory exhausted issue.
>
>The new compiler I built using spawn() yesterday 
>has not exhibited this behaviour yet.
>
>If you have any advice on how to track down the issues I'd be glad to try
>it out.  I checked the web (cygwin & google) for similar references and
>found a few similar issues
>but no mention of a solution.
>
>ken faiczak
>
>>
>>Cygwin does have a working fork().  Whether it should use fork or
>>spawn is up to the cygwin folks, but it looks like what you propose is
>>correct.  Still...
>>
>>1. Your patch is backwards (should be diff old new, not diff new old)
>>2. Please use "cvs diff -p -c 3"
>>3. Please include a ChangeLog entry with each patch.
>
>I don't see any reason to special case Cygwin any more, so I think the
>correct way to deal with this is to remove all of the if*def CYGWINs
>from this file since they are now meaningless.
>
>I don't know what caused the fork error but, since fork is alive and
>well in thousands of other programs, it is hard to believe that it is
>a generic bug in fork.  If it is, it should definitely be fixed.
>
>I ch
>
>cgf
>
>>> 254c254
>>> < #if (defined (_WIN32) || defined(__CYGWIN__)) && ! defined (_UWIN)
>>> ---
>>> > #if defined (_WIN32) && ! defined (_UWIN)
>>> 665c665
>>> <     && ! ((defined (_WIN32) || defined(__CYGWIN__)) && ! defined
>(_UWIN))
>>> ---
>>> >     && ! (defined (_WIN32) && ! defined (_UWIN))

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list