unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sam Steingold <sds@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: threads and kill-buffer
Date: Wed, 05 Sep 2012 12:50:46 -0400	[thread overview]
Message-ID: <87627s8lcp.fsf@gnu.org> (raw)
In-Reply-To: 834nnce8bs.fsf@gnu.org

> * Eli Zaretskii <ryvm@tah.bet> [2012-09-05 19:35:35 +0300]:
>
>> From: Sam Steingold <sds@gnu.org>
>> Date: Wed, 05 Sep 2012 10:20:47 -0400
>> 
>> > * Eli Zaretskii <ryvm@tah.bet> [2012-09-05 05:53:56 +0300]:
>> >
>> > How about letting kill-buffer succeed, but delay the actual deletion
>> > of the buffer until no thread has it as current, like what Posix
>> > filesystems do with file deletion?
>> 
>> I am not sure that Posix file systems do this "by design" and not as a
>> side effect of an implementation detail.
>
> Why does it matter?  If we implement the same logic for buffers, it
> will surely be by design.

Because this is a bad behavior.
The fact that posix does it, does not prove that it is good.
Why do we need to copy other people's mistakes, especially when those
mistakes might be unintended side effects of other design decisions
(i.e., even its authors would agree that it was a mistake)?

>> It is a certain way to lose data: imagine thread T1 moving data from
>> buffer B1 to buffer B2 and thread T2 killing one of these buffers.
>> Killing B1 is fine, but killing B2 will lose data. Note that being the
>> current buffer of another thread is an insufficient protection because a
>> thread may be writing to several buffers and only one of them may be
>> current to it, so a thread should be able to mark a buffer as used by
>> it, so that an attempt to kill a buffer used by a live thread would
>> result in an exception.
>
> That's an entirely different problem than the one that started this
> thread.  The original problem was that each thread must have a current
> buffer, and what to do when it is deleted by another thread.  That
> problem is not about losing data at all, it's about gobs of Emacs
> internals that assume there's always a current buffer that is a live
> buffer.

Yes, but sometimes it is a good idea to look at a problem in a wider
context.
Specifically, the problem I describe suggests a solution to the problem
you describe: when a thread sets its current buffer, that thread should
be added to that buffer's users list which would prevent all other
threads from killing it.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://memri.org http://camera.org http://truepeace.org
http://mideasttruth.com http://pmw.org.il http://iris.org.il
If you do not move, you will not feel the shackles.




  reply	other threads:[~2012-09-05 16:50 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04 20:36 threads and kill-buffer Tom Tromey
2012-09-04 20:43 ` Lars Ingebrigtsen
2012-09-04 21:03 ` Paul Eggert
2012-09-05  2:53 ` Eli Zaretskii
2012-09-05 14:20   ` Sam Steingold
2012-09-05 16:35     ` Eli Zaretskii
2012-09-05 16:50       ` Sam Steingold [this message]
2012-09-05 16:54         ` Eli Zaretskii
2012-09-05 19:19         ` Stephen J. Turnbull
2012-09-05 20:34           ` Tom Tromey
2012-09-06  0:20             ` Stephen J. Turnbull
2012-09-06  1:53               ` Tom Tromey
2012-09-06  8:34                 ` Stephen J. Turnbull
2012-09-05 18:13     ` Stefan Monnier
2012-09-05 18:28     ` Tom Tromey
2012-09-05 19:14       ` Stefan Monnier
2012-09-05 18:20   ` Tom Tromey
2012-09-05 19:00     ` Stephen J. Turnbull
2012-09-05 19:10       ` Tom Tromey
2012-09-05 19:50         ` Eli Zaretskii
2012-09-05 20:48           ` Stephen J. Turnbull
2012-09-06  5:16             ` Eli Zaretskii
2012-09-06  9:22               ` Stephen J. Turnbull
2012-09-06 10:58                 ` Eli Zaretskii
2012-09-07  1:26                   ` Stephen J. Turnbull
2012-09-05 20:25         ` Stephen J. Turnbull
2012-09-05 19:45       ` Eli Zaretskii
2012-09-05 19:46     ` Eli Zaretskii
2012-09-06  2:28       ` Stefan Monnier
2012-09-06  5:24         ` Eli Zaretskii
2012-09-06 12:32           ` Stefan Monnier
2012-09-05  3:49 ` SAKURAI Masashi
2012-09-05  4:34 ` Dmitry Antipov
2012-09-05  9:44   ` martin rudalics
2012-09-05 16:28     ` Eli Zaretskii
2012-09-06  7:19       ` martin rudalics
2012-09-06  7:56         ` Eli Zaretskii
2012-09-06 14:41           ` martin rudalics
2012-09-06 14:55             ` Eli Zaretskii
2012-09-06 16:04               ` martin rudalics
2012-09-06 17:07                 ` Stefan Monnier
2012-09-06 17:37                   ` martin rudalics
2012-09-06 18:22                     ` Eli Zaretskii
2012-09-06 19:25                       ` Eli Zaretskii
2012-09-07  9:52                       ` martin rudalics
2012-09-06 21:28                     ` Stefan Monnier
2012-09-07  9:52                       ` martin rudalics
2012-09-07 14:44                         ` Stefan Monnier
2012-09-07 16:13                           ` martin rudalics
2012-09-07 18:31                             ` Stefan Monnier
2012-09-06 20:49             ` PJ Weisberg
2012-09-07  5:52               ` Eli Zaretskii
2012-09-07 15:28                 ` PJ Weisberg
2012-09-08 14:58                   ` Nix
2012-09-08 15:21                     ` Eli Zaretskii
2012-09-08 19:45                     ` Stefan Monnier
2012-09-05 13:41 ` Stefan Monnier
2012-09-05 14:34   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87627s8lcp.fsf@gnu.org \
    --to=sds@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).