From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: threads and kill-buffer Date: Thu, 06 Sep 2012 05:25:25 +0900 Message-ID: <87pq60rzd6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87a9x55xvd.fsf@fleche.redhat.com> <83d321dvsr.fsf@gnu.org> <87d320qqkp.fsf@fleche.redhat.com> <87vcfss3b0.fsf@uwakimon.sk.tsukuba.ac.jp> <87r4qgp9pz.fsf@fleche.redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1346876736 19791 80.91.229.3 (5 Sep 2012 20:25:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 20:25:36 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 22:25:37 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 1T9MAL-0001pp-Mg for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 22:25:37 +0200 Original-Received: from localhost ([::1]:37264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MAI-0000ri-Mi for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 16:25:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MAF-0000ff-7c for emacs-devel@gnu.org; Wed, 05 Sep 2012 16:25:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9MAE-0005Ri-EB for emacs-devel@gnu.org; Wed, 05 Sep 2012 16:25:31 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:55034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MAC-0005RI-UE; Wed, 05 Sep 2012 16:25:29 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id F35899708BE; Thu, 6 Sep 2012 05:25:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B5E371A4BAF; Thu, 6 Sep 2012 05:25:25 +0900 (JST) In-Reply-To: <87r4qgp9pz.fsf@fleche.redhat.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:153076 Archived-At: Tom Tromey writes: > >> I have been thinking about it and the only issue I see is that, > >> since it introduces a new buffer state, > > Stephen> Not one that's visible to Lisp. Why would it be? > > It is visible because in thread T, the buffer is still the current > buffer, but is semi-live. On the trunk (buffer-live-p (current-buffer)) > can never be nil, but under this proposed change, it could be. Yeah, well, threads mess with your mind. What else is new? I mean, on the trunk (buffer-live-p (current-buffer)) can't return 'killed-but-not-dead, either. Why would it start doing so now? ;-) My point is that at this point the thread is clearly not manipulating the buffer, so buffer-live-p can safely change the current buffer (in the sense that it won't mess up Emacs's internal structures, although it might play havoc with user data).[1] However, it may as well return nil which tells the thread that what it thinks is the current buffer is dead. Of course, you could introduce the notion of object owner, and disallow any thread but the object's owner from killing/deleting an object. But that still isn't going to save you from all the other nefarious things that other threads can do to your objects. > Yeah, but the question is exactly how to give up. Concurrently. Footnotes: [1] In practice I would expect that actually the Lisp engine does this at some point.