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: Dynamic modules: MODULE_HANDLE_SIGNALS etc. Date: Thu, 24 Dec 2015 21:15:13 +0200 Message-ID: <83y4cjmzem.fsf@gnu.org> References: <83mvu1x6t3.fsf@gnu.org> <83r3iht93x.fsf@gnu.org> <838u4psznr.fsf@gnu.org> <56772054.8010401@cs.ucla.edu> <83zix4scgf.fsf@gnu.org> <5677DBC9.6030307@cs.ucla.edu> <83io3rst2r.fsf@gnu.org> <567841A6.4090408@cs.ucla.edu> <567844B9.2050308@dancol.org> <5678CD07.8080209@cs.ucla.edu> <5678D3AF.7030101@dancol.org> <5678D620.6070000@cs.ucla.edu> <83mvt2qxm1.fsf@gnu.org> <56797CD9.8010706@cs.ucla.edu> <8337uuqsux.fsf@gnu.org> <5679DC83.70405@cs.ucla.edu> <83oadhp2mj.fsf@gnu.org> <567AD556.6020202@cs.ucla.edu> <567AD766.3060608@dancol.org> <567B5DAB.2000900@cs.ucla.edu> <83fuyromig.fsf@gnu.org> <567C25B1.3020101@dancol.org> <831taboike.fsf@gnu.org> <567C3417.5090303@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1450984485 8184 80.91.229.3 (24 Dec 2015 19:14:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 19:14:45 +0000 (UTC) Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 24 20:14:44 2015 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 1aCBLX-0006o0-Tc for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 20:14:44 +0100 Original-Received: from localhost ([::1]:33132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCBLX-0004y3-5e for ged-emacs-devel@m.gmane.org; Thu, 24 Dec 2015 14:14:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCBLT-0004xT-8Z for Emacs-devel@gnu.org; Thu, 24 Dec 2015 14:14:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aCBLO-0002DM-Rh for Emacs-devel@gnu.org; Thu, 24 Dec 2015 14:14:39 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aCBLO-0002DF-Ol; Thu, 24 Dec 2015 14:14:34 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3169 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aCBLO-0007Sg-13; Thu, 24 Dec 2015 14:14:34 -0500 In-reply-to: <567C3417.5090303@dancol.org> (message from Daniel Colascione on Thu, 24 Dec 2015 10:06:15 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:196787 Archived-At: > Cc: eggert@cs.ucla.edu, Emacs-devel@gnu.org > From: Daniel Colascione > Date: Thu, 24 Dec 2015 10:06:15 -0800 > > >> You'd prefer Emacs to lock up or corrupt data instead? > > > > Instead of crashing and corrupting data? What's the difference? > > > > Of course, if it would do that all the time, or even most of the time, > > we'd consider the solution a bad one, and remove it or look for ways > > of improving it. But we are not there; in most cases the recovery > > doesn't hang and doesn't corrupt any data. > > How would we know? I was talking based on my own testing of the feature, back when I implemented it for MS-Windows. > In any case, I expect the undefined-behavior problem to be worse in a > modules-heavy system, since most of the Emacs core code is written to > use non-local control flow for error reporting already, and since it > uses the GC for resource cleanup. I expect module code to be written in > a style less tolerant of arbitrary non-local control flow. Maybe you are right, it remains to be seen. If indeed this is what will happen, we will have to deal with that. > I have seen no evidence that C stack overflow is a real problem that > justifies the risks inherent in the current error handling scheme. If it's not a real problem, then this entire discussion was moot, since the code we are discussing will never run. > In any case, the possibility of the C stack overflowing during GC isn't > relevant to this discussion, since that has isn't covered by the current > logic anyway. Yes, but by artificially reducing available stack space, we might make such irrecoverable problems more frequent. > > It > > sounds like just making the stack larger is a better and easier > > solution. > > I'd be perfectly happy deleting the stack overflow code entirely and > increasing the declared stack size (on platforms where we ask for it). If we think the current stack size is borderline, we could do that regardless. The lower the probability of stack overflow recovery to be needed, the better. > > Threads make this even more complicated. At least on Windows, by > > default each thread gets the same amount of memory reserved for its > > stack as recorded by the linker in the program's header, i.e. 8MB in > > our case. So several threads can easily eat up a large portion of the > > program's address space, and then the actual amount of stack is much > > smaller than you might think. > > We don't have to run Emacs on the main thread. We could, instead, with > minimal code changes, call CreateThread on startup, supplying a larger > stack size that applies only to that thread. Or we can let X=8MB and > Y=2MB (the system default). Yes, we could. Assuming that Someone™ does the work of changing the code that assumes that the main thread runs Lisp etc. > I'm not clear on what you mean by "stack is smaller than you might > think": on both POSIX systems and on Windows, thread stacks are address > space reservations made at thread creation time. If we can't fit another > thread stack in the current address space, the failure mode is thread > creation failing, not thread stacks being undersized. I think lack of address space might mean the thread starts, but then hits stack overflow, because the stack couldn't be expanded. Also, at least on Windows the expression of this failure might be non-obvious. For example, we had a bug a couple of years ago where the file selection dialog won't pop, or popped and then behaved incorrectly, for this very reason. Windows sometimes starts threads on behalf of a process outside of our control. > > So on balance, I don't see how your proposal is better. > > I'm really not sure what's balancing the risk of data corruption and > lockups caused by the stack overflow code. Emacs got along fine for > decades before Dmitry added the stack overflow check late last year. And I'm sure we will get along fine for many years hence.