Re: threads and kill-buffer

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Tom Tromey <address@hidden>,
>     address@hidden
> Date: Thu, 06 Sep 2012 05:48:18 +0900
> 
> 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).

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

> Suppose the buffer is being used as (gasp!) a buffer, more
> precisely, a message queue.  If the writer is done, and kills the
> buffer, the reader wants to detect this after it's done reading, and
> 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.

> So here we have two extreme scenarios, one where the thread whose
> current buffer has met an untimely death wants to stop immediately,
> and another where it wants to finish up what it's doing completely.
> It's not hard to imagine cases where a killed current buffer is an
> error.  So the code needs to be able to find out the state of a
> buffer.

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,
so we don't need to be bothered by it too much, I think.  If and when
this is implemented, people who write Lisp code where the reader and
the writer run in different threads will need to use synchronization
devices other than buffer-live-p.