Re: threads and kill-buffer

[Eli Zaretskii <eliz@gnu.org>]

> From: Sam Steingold <sds@gnu.org>
> Date: Wed, 05 Sep 2012 12:50:46 -0400
> 
> > * 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.

It is used by quite a lot of programs, including GNU Coreutils
(AFAIR).

> 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)?

We don't _need_ to copy anything, unless we decide that this paradigm
is useful for the problem at hand.

> > 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.

But you aren't looking at the same problem.  You are looking at a
different problem, with potentially a quite different solution.