From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: advice needed for multi-threading patch Date: Mon, 28 Sep 2009 23:20:59 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254194479 30796 80.91.229.12 (29 Sep 2009 03:21:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Sep 2009 03:21:19 +0000 (UTC) Cc: Tom Tromey , Emacs development discussions To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 29 05:21:12 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MsTH5-0007QX-DC for ged-emacs-devel@m.gmane.org; Tue, 29 Sep 2009 05:21:11 +0200 Original-Received: from localhost ([127.0.0.1]:54538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsTH4-0000TM-G4 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 23:21:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsTGz-0000Sy-Hi for emacs-devel@gnu.org; Mon, 28 Sep 2009 23:21:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsTGu-0000Rn-Vj for emacs-devel@gnu.org; Mon, 28 Sep 2009 23:21:04 -0400 Original-Received: from [199.232.76.173] (port=51726 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsTGu-0000Rk-NC for emacs-devel@gnu.org; Mon, 28 Sep 2009 23:21:00 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:34798 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsTGu-0004eL-EA for emacs-devel@gnu.org; Mon, 28 Sep 2009 23:21:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAIMZwUpFxIo//2dsb2JhbACBUdVkgjOBawWHfg X-IronPort-AV: E=Sophos;i="4.44,470,1249272000"; d="scan'208";a="46767851" Original-Received: from 69-196-138-63.dsl.teksavvy.com (HELO pastel.home) ([69.196.138.63]) by ironport2-out.pppoe.ca with ESMTP; 28 Sep 2009 23:20:59 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 16A1A80C4; Mon, 28 Sep 2009 23:20:59 -0400 (EDT) In-Reply-To: (Ken Raeburn's message of "Mon, 28 Sep 2009 22:26:56 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115769 Archived-At: >> You seem to say that it should return "/foo", but currently it returns >> something else. Maybe we should try to come up with a run-time test to >> catch such cases in current Lisp code. > I suspect that any sensible approach we come up with is going to > involve a change in behavior that may affect some existing code. So coming > up with ways to detect code that changes meaning is probably going to > be a good idea. Yes, that's what I meant. >> A related case is when a process filter or a sentinel is run via >> accept-process-output: we'd need to be careful to make sure the code >> is run in the same thread as the code that called >> accept-process-output. > Not necessarily; two threads could each be running helper programs in > subprocesses (or using network connections), setting up let-bound > variables, and calling accept-process-output, expecting the process filters > to have access to the let-bound variables. I think you're thinking of the case where accept-process-output is called without specifying any particular process to wait for, whereas I was thinking of the case where accept-process-output is called with a process argument. >> Redisplay should be run in a completely separate thread (at least >> conceptually). > I think it's less likely, but a package might also let-bind some variables > that affect the display (e.g., truncate-lines, selective- > display, show-trailing-whitespace, all of which are buffer-local, or > anything referenced via mode-line) and then call y-or-n-p or read-file- > name or some other routine that will trigger redisplay and prompt the user > for some info that may depend on what's displayed.... Yes, I know this happens with things like cursor-in-echo-area, tho this is a global variable. Not sure how often (or even if) this happens with buffer-local vars. > So... yeah, I think I like the conceptually-separate-thread approach better, > even if it could break existing code. I'm not certain we couldn't do > better in terms of backwards compatibility, but it's simple and clean. It's improtant to maximize backward compatibility, but it's also to try and avoid getting locked in overly complex semantics, especially in the long run. Stefan