Re: threads and kill-buffer

[Stephen J. Turnbull]

Tom Tromey writes:
 > >> I have been thinking about it and the only issue I see is that,
 > >> since it introduces a new buffer state,
 > 
 > Stephen> Not one that's visible to Lisp.  Why would it be?
 > 
 > It is visible because in thread T, the buffer is still the current
 > buffer, but is semi-live.  On the trunk (buffer-live-p (current-buffer))
 > can never be nil, but under this proposed change, it could be.

Yeah, well, threads mess with your mind.  What else is new?  I mean,
on the trunk (buffer-live-p (current-buffer)) can't return
'killed-but-not-dead, either.  Why would it start doing so now? ;-)

My point is that at this point the thread is clearly not manipulating
the buffer, so buffer-live-p can safely change the current buffer (in
the sense that it won't mess up Emacs's internal structures, although
it might play havoc with user data).[1]  However, it may as well return
nil which tells the thread that what it thinks is the current buffer
is dead.

Of course, you could introduce the notion of object owner, and
disallow any thread but the object's owner from killing/deleting an
object.  But that still isn't going to save you from all the other
nefarious things that other threads can do to your objects.

 > Yeah, but the question is exactly how to give up.

Concurrently.

Footnotes: 
[1]  In practice I would expect that actually the Lisp engine does
this at some point.