Re: threads and kill-buffer

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Again, I was primarily bothered with preserving the existing
 > semantics, not to allow new features.

You don't need to do anything to preserve existing semantics of
accessing buffers.  Lisp can already run asynchronously, including
killing the current buffer out from under a running function.  The
feature you propose (and I agree with) allows a thread with a dying
current buffer to do something useful with it before current buffer
changes.  The new semantics is due to your feature.  The question is,
in these new semantics, what is the return value of (buffer-live-p
(current-buffer))?  Returning t is not useful.  Returning nil
preserves existing semantics of code that actually checks for liveness
of the current buffer, and allows code that knows about the new
semantics to do something more useful (if that option is available,
which depends on the code).

 > I meant to say that the old code that runs in a single thread will
 > still work, in the presence of other threads that do unrelated things,
 > like fetch news group articles.

Sure, but it doesn't matter what (buffer-live-p (current-buffer))
returns while current buffer is dying, that old code will still work.

 > > Having a buffer killed out from under my code is hardly the first
 > > thing I'd worry about if I were writing a threaded program.
 > 
 > And you'd be wrong: lots of low-level internals in Emacs assume
 > without checking that the current buffer exists and is valid.  E.g.,
 > redisplay will crash and burn if that somehow became false in the
 > middle of its work.

Yeah, and this just isn't going to happen in correct programs.  The
risk is low except in experimental or one-off code, and even there I
only kill buffers that I've created.  Do you really do

    (let ((bl (buffer-list)))
      (kill-buffer (nth (random (length bl)) bl)))

so frequently?  Yes, it's something to worry about in the internals,
but (a) at this point in time it's relatively low priority vs getting
the semantics of threading right and (b) your proposal fixes that.

 > If that's what is desired, then thread B could switch away from that
 > buffer, after killing it, and Bob's our uncle.

In the scenario we're concerned about (defective code that kills
somebody else's buffer), that's not what is desired.  You're
completely missing the point.  This entire discussion is "Is there a
more useful return value than t for (buffer-live-p (current-buffer))
when we are surprised by the current buffer being killed by another
thread?"  (Assuming that the current buffer is preserved for our
thread until it switches away.)  

 > > You could also remove the recursive calls and just loop:
 > > 
 > > (while t (writer) (reader))
 > 
 > And why is this a problem in the context of this discussion?  No
 > buffer is killed anywhere in sight, AFAICS.

But that's the *whole* point of this discussion!  *The buffer killing
takes place out of sight.*