Re: threads and kill-buffer

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: tromey@redhat.com,
>     emacs-devel@gnu.org
> Date: Thu, 06 Sep 2012 18:22:01 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
>  > > If the thread wants to do anything further with this buffer, it must
>  > > do so before switching buffers, because the current (dead) buffer
>  > > will become inaccessible as soon as it does switch buffers.
>  > 
>  > This is another problem, one that exists today: switching buffers
>  > could kill the buffer we are switching away of (e.g., via some hook).
> 
> No, because there's nothing we can do about such a hook unless we put
> it there, and nobody does.  Under the proposed "POSIX deletion"
> semantics, however, we can know it's coming, as long as we can detect
> that the current buffer is killed.  And we are guaranteed that we can
> read it, we can save it, etc.

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

>  > > Even to the extent that it is possible, I don't see why it's a good
>  > > idea.
>  > 
>  > Because it keeps the old code in working condition, and it keeps the
>  > programmer sane.
> 
> Well, no.  Old code won't work (it will deadlock, interleave writes
> that should be sequenced, etc) without being rewritten for threaded
> environments, unless it's only ever used single-threaded anyway.

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.  If the old code is rewritten to take
advantage of threads, it will have to be adapted to this issue as part
of the rewrite.

> Unless you're talking about some random other thread killing your
> buffers

Yes.

> in which case killing a buffer is only one of the more drastic of
> nasty things that other thread could do.

That's the "nasty thing" Tom raised in this discussion, so that's what
I'm talking about.  Other nasty things warrant separate discussions.

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

> I'm describing the semantics of a buffer X killed by thread A as seen
> from thread B where it is current, and according to your proposal to
> thread B thqe buffer will appear to be live indefinitely.  If thread B
> is the reader, it will never detect that the buffer is dead, and will
> keep on trying to read from it forever when it could be doing useful
> work.
> 
> Yes, you could use an alternative synchronization method where thread
> A explicitly sends thread B a message "hey, I killed your buffer", but
> why make the user do it when "buffer is dying, so let's read what's
> left and then get on with our life" will automatically DTRT?

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

IOW, you can write your code so that a killed buffer disappears
shortly, if that's what you need.

>  > If you mean that the same buffer is current in both the reader and the
>  > writer, then that's a situation that cannot exist in the current code,
> 
> What do you mean by "current code"?

The code on the trunk.

> (defvar read-mark (make-marker))
> 
> (defun writer ()
>   (set-marker read-mark (point))
>   (insert "Hi, Eli!\n")
>   (reader))
> 
> (defun reader ()
>   (mail-to-eli (buffer-substring read-mark (point)))
>   (writer))
> 
> (writer)
> 
> No set-buffers needed.  Everything in the current buffer.

Invalid programs are not interesting for discussing design decisions.

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