emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: threads and kill-buffer


From: Stephen J. Turnbull
Subject: Re: threads and kill-buffer
Date: Thu, 06 Sep 2012 18:22:01 +0900

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <address@hidden>

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

 > > 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.  In
that case there's no problem in the first place.  Unless you're
talking about some random other thread killing your buffers, in which
case killing a buffer is only one of the more drastic of nasty things
that other thread could do.

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.

 > > quit reading.  Under your semantics (including your proposal that the
 > > KILLED_BUT_NOT_DEAD state not be available to Lisp), it can't.
 > 
 > Why can't it?  The buffer is killed, so it doesn't exist, and the
 > reader will detect that right away, like it does now.  Maybe I don't
 > understand the situation you are describing.

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 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 trunk or Tom's branch?  And
why can't it exist?  Eg,

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

Of course this is an error in Emacs Lisp as it stands, since it will
blow the stack.  But it could run quite a while (as far as your
overful mailbox is concerned, anyway).  And once you've got threads,
instead of mutually recursive cooperative coroutines, you can
implement them as ordinary loops.

You could also remove the recursive calls and just loop:

(while t (writer) (reader))

 > so we don't need to be bothered by it too much, I think.

I don't understand this at all.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]