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:48:18 +0900 Message-ID: <87oblkryb1.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> <83r4qgckqm.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1346878110 31534 80.91.229.3 (5 Sep 2012 20:48:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 20:48:30 +0000 (UTC) Cc: Tom Tromey , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 22:48:29 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 1T9MWT-0000h7-K5 for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 22:48:29 +0200 Original-Received: from localhost ([::1]:50934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MWQ-0002HN-Ou for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 16:48:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MWO-0002HF-Ci for emacs-devel@gnu.org; Wed, 05 Sep 2012 16:48:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9MWN-0004ED-EH for emacs-devel@gnu.org; Wed, 05 Sep 2012 16:48:24 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:55199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MWL-0004DF-HY; Wed, 05 Sep 2012 16:48:21 -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 73AA3970857; Thu, 6 Sep 2012 05:48:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 34E121A4BAF; Thu, 6 Sep 2012 05:48:18 +0900 (JST) In-Reply-To: <83r4qgckqm.fsf@gnu.org> 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:153078 Archived-At: Eli Zaretskii writes: > I think we should try to arrange things in such a way that for a > thread that has this buffer as current everything looks and feels > as if the buffer were not killed at all. This isn't possible. If the thread wants to do anything further with this buffer, it must do so before switching buffers, because the current (dead) buffer will become inaccessible as soon as it does switch buffers. Even to the extent that it is possible, I don't see why it's a good idea. Suppose the buffer is being used as (gasp!) a buffer, more precisely, a message queue. If the writer is done, and kills the buffer, the reader wants to detect this after it's done reading, and quit reading. Under your semantics (including your proposal that the KILLED_BUT_NOT_DEAD state not be available to Lisp), it can't. Similarly, if the reader is done, and kills the buffer, the writer wants to detect this *before* writing any more, and quit writing. So here we have two extreme scenarios, one where the thread whose current buffer has met an untimely death wants to stop immediately, and another where it wants to finish up what it's doing completely. It's not hard to imagine cases where a killed current buffer is an error. So the code needs to be able to find out the state of a buffer. The question is whether it's useful for there to be a third state. I don't think so; everything you need to know is encapsulated in the fact that the buffer is dead (to the rest of Emacs) and current.