From: Jesse Ziser <ziser@arlut.utexas.edu>
To: cygwin@cygwin.com
Subject: Re: "Couldn't allocate heap" - tried rebasing
Date: Wed, 23 Nov 2011 15:37:00 -0000 [thread overview]
Message-ID: <4ECD104C.8010907@arlut.utexas.edu> (raw)
In-Reply-To: <4ECC7565.2090304@cygwin.com>
On 11/22/2011 10:24 PM, Larry Hall (Cygwin) wrote:
> On 11/22/2011 8:08 PM, Jon Clugston wrote:
>>>
>>> Actually, I just noticed this remark:
>>>
>>> "In summary, current Windows implementations make it
>>> impossible to implement a perfectly reliable fork, and occasional
>>> fork failures are inevitable."
>>>
>>> in winsup/doc/overview2.sgml in the source tree. Does that mean that,
>>> even
>>> with the improvements mentioned above, we cannot expect important Cygwin
>>> apps/scripts to always work reliably in a post-WinXP world? My
>>> company has
>>> been moving from Win2K/XP to Win7, so this would be important info
>>> for us.
>>>
>>> So how serious is the above remark? I don't see anything quite that
>>> strongly-phrased in the FAQ. Maybe it should be mentioned there?
>>>
>>
>> I would assume that "current Windows implementations" means XP and
>> above. I have found it to be quite stable on Windows 7 once a rebase
>> is done. I also believe that the possibility of "fork" failing has
>> always been there - even in Cygwin 1.5. So, maybe the remark is not
>> quite as scary as it might at first appear.
>
> The fork issue is nothing new. It has existed for a long time. The 1.5
> series was certainly not immune. The fact that fork failures may be more
> prevalent now than before has as much to do with the growth in the number
> of packages available with Cygwin as it does with the changes in the
> Windows environment that work against the fork implementation. And there
> have been efforts to combat the negative impacts of both of these changes,
> particularly in post 1.7.9 snapshots (and eventually packages. :-) ) My
> recommendation is to not worry about fork failures until you see them and
> then install the rebase package, read the readme, and follow the directions
> found there. In other words, don't worry more now than you did before. ;-)
OK. From that document I had gotten the impression that the
inevitability of the problem was related to Address Space Layout
Randomization introduced in Windows Vista, and therefore, XP had been in
a better situation. If the probability of problems after the latest
snapshot on Win7 is the same as it's always been on WinXP, then I guess
we'll be no more or less likely than before to see these issues. Thanks.
--
+---------------------------+
| Jesse Ziser, Code Warrior |
| Applied Research Labs: UT |
+---------------------------+
--
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
next prev parent reply other threads:[~2011-11-23 15:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 16:00 Jesse Ziser
2011-11-11 18:29 ` Ken Brown
2011-11-15 17:34 ` Jesse Ziser
2011-11-22 23:43 ` Jesse Ziser
2011-11-23 1:08 ` marco atzeri
2011-11-23 3:26 ` Jon Clugston
2011-11-23 5:10 ` Larry Hall (Cygwin)
2011-11-23 15:37 ` Jesse Ziser [this message]
2011-11-23 4:24 ` Mark Geisert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ECD104C.8010907@arlut.utexas.edu \
--to=ziser@arlut.utexas.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).