public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
* FW: Random fork failures
@ 2017-08-25 13:22 Carter, Mark Andrew (Andy)
  2017-08-25 14:38 ` cyg Simple
  2017-08-25 16:16 ` Corinna Vinschen
  0 siblings, 2 replies; 3+ messages in thread
From: Carter, Mark Andrew (Andy) @ 2017-08-25 13:22 UTC (permalink / raw)
  To: cygwin-developers

We are experiencing an increasing frequency of fork failures in moving our 32 bit application to Windows 10.  Rebaseall is only a temporary fix.  Preliminary unit testing using this "https://github.com/s-u/multicore/blob/master/src/forknt.c" code have been successful.  Would it be fruitful to replace the Cygwin fork with this implementation?  I do not want to waste my time repeating another's work or pursuing a known dead end.

- Andy Carter

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: FW: Random fork failures
  2017-08-25 13:22 FW: Random fork failures Carter, Mark Andrew (Andy)
@ 2017-08-25 14:38 ` cyg Simple
  2017-08-25 16:16 ` Corinna Vinschen
  1 sibling, 0 replies; 3+ messages in thread
From: cyg Simple @ 2017-08-25 14:38 UTC (permalink / raw)
  To: cygwin-developers

On 8/25/2017 9:22 AM, Carter, Mark Andrew (Andy) wrote:
> We are experiencing an increasing frequency of fork failures in moving our 32 bit application to Windows 10.  Rebaseall is only a temporary fix.  Preliminary unit testing using this "https://github.com/s-u/multicore/blob/master/src/forknt.c" code have been successful.  Would it be fruitful to replace the Cygwin fork with this implementation?  I do not want to waste my time repeating another's work or pursuing a known dead end.
> 

Please forward your conversation to cygwin@cygwin.com.  The
cygwin-developers list is reserved for conversations of developing the
Cygwin DLL.

-- 
cyg Simple

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: FW: Random fork failures
  2017-08-25 13:22 FW: Random fork failures Carter, Mark Andrew (Andy)
  2017-08-25 14:38 ` cyg Simple
@ 2017-08-25 16:16 ` Corinna Vinschen
  1 sibling, 0 replies; 3+ messages in thread
From: Corinna Vinschen @ 2017-08-25 16:16 UTC (permalink / raw)
  To: cygwin-developers

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On Aug 25 08:22, Carter, Mark Andrew (Andy) wrote:
> We are experiencing an increasing frequency of fork failures in moving
> our 32 bit application to Windows 10.  Rebaseall is only a temporary
> fix.  Preliminary unit testing using this
> "https://github.com/s-u/multicore/blob/master/src/forknt.c" code have
> been successful.  Would it be fruitful to replace the Cygwin fork with
> this implementation?  I do not want to waste my time repeating
> another's work or pursuing a known dead end.

This implementation won't work as desired.  It's a nice idea and I tried
and tested something similar once.  The downside is that, even if the NT
kernel can fork, the Win32 subsystem doesn't allow this to be done
cleanly.  For instance, after a fork, the connection to the current
Windows console, user32 and gdi32 initialization are broken in the child
and more along these lines.  I talked to guys at Microsoft about this
and they basically waved their hands.

Move to 64 bit Cygwin is what you should do.

If that doesn't work for you, reduce the number of installed DLLs to
lower the footprint and make sure to reduce BLODA interference.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-08-25 16:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-25 13:22 FW: Random fork failures Carter, Mark Andrew (Andy)
2017-08-25 14:38 ` cyg Simple
2017-08-25 16:16 ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).