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 04:00:19 +0900 Message-ID: <87vcfss3b0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87a9x55xvd.fsf@fleche.redhat.com> <83d321dvsr.fsf@gnu.org> <87d320qqkp.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 1346871641 31475 80.91.229.3 (5 Sep 2012 19:00:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 19:00:41 +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 21:00:43 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 1T9KqA-0001fv-Pk for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 21:00:43 +0200 Original-Received: from localhost ([::1]:46689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9Kq7-0005RK-UF for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 15:00:39 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9Kq1-0005Qg-QT for emacs-devel@gnu.org; Wed, 05 Sep 2012 15:00:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9Kps-0002VQ-F1 for emacs-devel@gnu.org; Wed, 05 Sep 2012 15:00:33 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:54442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9Kpq-0002Rx-Mf; Wed, 05 Sep 2012 15:00:22 -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 9E9059708BF; Thu, 6 Sep 2012 04:00:19 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5CDAC1A4BAF; Thu, 6 Sep 2012 04:00:19 +0900 (JST) In-Reply-To: <87d320qqkp.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:153068 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, Not one that's visible to Lisp. Why would it be? > we would have to decide what buffer-live-p returns for a buffer > that is killed-but-not-yet-dead. nil. If a thread calls buffer-live-p, that means it's prepared to recover if b-l-p returns nil. I suppose you're thinking that the thread might want to snarf the data before the memory gets reallocated or something like that, but if other threads are killing your buffers, who knows what they might be doing to the contents? Better to just give up.