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: threads and kill-buffer Date: Thu, 06 Sep 2012 08:16:39 +0300 Message-ID: <83obljd93c.fsf@gnu.org> 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> <87oblkryb1.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1346908595 23268 80.91.229.3 (6 Sep 2012 05:16:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2012 05:16:35 +0000 (UTC) Cc: tromey@redhat.com, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 07:16:36 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 1T9USB-0007o9-2x for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 07:16:35 +0200 Original-Received: from localhost ([::1]:42350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9US8-0006xj-47 for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2012 01:16:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9US5-0006xT-Al for emacs-devel@gnu.org; Thu, 06 Sep 2012 01:16:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9US4-0007AH-3W for emacs-devel@gnu.org; Thu, 06 Sep 2012 01:16:29 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:65513) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9US3-0007A9-Rs for emacs-devel@gnu.org; Thu, 06 Sep 2012 01:16:28 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M9W00200XAKS200@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 06 Sep 2012 08:16:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M9W002I7XBEKS40@a-mtaout22.012.net.il>; Thu, 06 Sep 2012 08:16:26 +0300 (IDT) In-reply-to: <87oblkryb1.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:153087 Archived-At: > From: "Stephen J. Turnbull" > Cc: Tom Tromey , > emacs-devel@gnu.org > Date: Thu, 06 Sep 2012 05:48:18 +0900 > > 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. This is another problem, one that exists today: switching buffers could kill the buffer we are switching away of (e.g., via some hook). > Even to the extent that it is possible, I don't see why it's a good > idea. Because it keeps the old code in working condition, and it keeps the programmer sane. > 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. Why can't it? The buffer is killed, so it doesn't exist, and the reader will detect that right away, like it does now. Maybe I don't understand the situation you are describing. > 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. If you mean that the same buffer is current in both the reader and the writer, then that's a situation that cannot exist in the current code, so we don't need to be bothered by it too much, I think. If and when this is implemented, people who write Lisp code where the reader and the writer run in different threads will need to use synchronization devices other than buffer-live-p.