From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: "resource temporarily unavailable" errors on windows 7 Date: Thu, 15 Mar 2012 06:04:00 +0200 Message-ID: <837gymwlvz.fsf@gnu.org> References: <83aa3lybos.fsf@gnu.org> <83vcm9w3th.fsf@gnu.org> <83obs0wb0p.fsf@gnu.org> <83d38fvzsc.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1331784250 17783 80.91.229.3 (15 Mar 2012 04:04:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2012 04:04:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alex Harsanyi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 15 05:04:09 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S81v7-0008HS-5q for ged-emacs-devel@m.gmane.org; Thu, 15 Mar 2012 05:04:09 +0100 Original-Received: from localhost ([::1]:54817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S81v6-0001iy-Dm for ged-emacs-devel@m.gmane.org; Thu, 15 Mar 2012 00:04:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43603) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S81v2-0001hj-LE for emacs-devel@gnu.org; Thu, 15 Mar 2012 00:04:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S81v0-00040d-JJ for emacs-devel@gnu.org; Thu, 15 Mar 2012 00:04:04 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:34655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S81v0-00040O-B0 for emacs-devel@gnu.org; Thu, 15 Mar 2012 00:04:02 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M0W00G00R6A5X00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Thu, 15 Mar 2012 06:04:00 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.179.236]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0W00GMKRAN2V30@a-mtaout23.012.net.il>; Thu, 15 Mar 2012 06:04:00 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149069 Archived-At: > Date: Thu, 15 Mar 2012 08:02:42 +0800 > From: Alex Harsanyi > Cc: emacs-devel@gnu.org >=20 > >> =A0 =A0cp->thrd =3D CreateThread (NULL, 64 * 1024, reader_thread= , cp, > >> 0x00010000, &id); > > > > And does this smaller stack reservation improve the situation, if= you > > return the initial memory request in allocate_heap to its origina= l > > value. > > >=20 > Yes it does. I'm using a build with allocate_heap starting at 2GB > (the original value) and this updated CreateThread call as my worki= ng > Emacs. I will continue to use it and I will report if I see any m= ore > errors. OK, thanks. If you don't see any problems with this, we could think about making this fix permanent. > Also, the strange dwStackSize interpretation by CreateThread was > tested on Windows 7 32 bit only. I'm not sure how this behaves on > other windows versions. Since we are in pretest, the prudent thing would be to condition this fix on that combination only. > Perhaps at minimum, the mingw build should be updated to use 1Mb st= ack > reservation in the program header? I don't want to do that in general, since Emacs on Windows uses threads for features other than interaction with subprocesses, and those other threads might need larger stack. Also, doesn't the value in the header determine the stack size of the main thread as well? I= f it does, then 8MB is there for a reason: Emacs devours a lot of stack space when it does GC, because GC is an extremely recursive process.