Re: threads and kill-buffer

[Stephen J. Turnbull]

Sam Steingold writes:

 > Because [one thread killing another's buffer] is a bad behavior.

Sure, but you're prosecuting an innocent man, Sam.  The culprit is not
kill-buffer semantics[1], it's threads, which *by design* impose the
responsibility for data safety on the programmer.  If one thread's
code can't destroy another thread's data with kill-buffer, then it can
use erase-buffer or `(progn (overwrite-mode) (goto-char (point-min))
(while (not (eobp)) (insert "DEADBEEF")))'.  More likely, it will just
insert "The boss is an idiot!" in a footnote somewhere in the 100-page
report you're turning in to said boss in 31 minutes. :-)

So threads are dangerous if the programmer is not extremely careful.
This is not news, and hamstringing kill-buffer isn't going to make
them all that much safer.  All we can do here is try to prevent Very
Bad Things from happening to third parties who never operate on that
buffer.  Eg, A starts writing to the buffer, B kills it, it gets GC'd
and reallocated, this time for byte-code running in thread C, and A
starts playing "core wars" with what it thinks is its current buffer.[2]

That's why POSIX file deletion semantics are a good idea.  Not because
they save data from users determined to destroy it, but because they
prevent at least some kinds of collateral damage to other processes or
the OS.

 > The fact that posix does it, does not prove that it is good.

Agreed.  Down With Threads!  :-)


Footnotes: 
[1]  I mean, really.  There's a reason we call it "killing the buffer!"

[2]  Before the thread advocates start stoning me, let me acknowledge
that this scenario is highly unlikely even in the worst case, and
more or less impossible for the kinds of applications normally
proposed for Emacs Lisp threads (eg, asynchronous I/O).  But it's at
least theoretically possible with preemptive threads and Sufficiently
Stupid Code[tm].