Re: Failing to GC killed buffers considered harmful

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Mon, 30 Mar 2020 15:40:31 -0400
> 
> > What are the advantages?
> 
> Simpler code.

<Shrug> I'm not sure I see the simplification, certainly not a
significant one that would justify the risks.  You've replaced one
macro with a similar (and subtly different) one which is used in the
same way.  You've also removed a single variable with a very simple
structure and use pattern.  I'm not sure I see the gains.

On the downside, I see a few possible pitfalls:

 . How did you test this?  In particularly, did it survive the test in
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39962#116?

 . We will be tracking buffers via Vbuffer_alist, from which we remove
   the killed buffer in kill-buffer much earlier than from
   all_buffers, and not inside a critical section -- cannot this cause
   some problems if there's a race in updating Vbuffer_alist?

 . What about the following comment earlier in this thread:

   > And yes, you do have to dump killed buffers. If we have a Lisp reference 
   > to a buffer and we can't dump buffers, what do we do? Fail the dump? 
   > Replace the reference with the integer 5?

   Does this issue no longer bother us?  If so, what changed our
   minds?

So I'm not sure why would we want to take the risk of breaking things
due to this change, given that the gains are minor at best.  Will this
allow us to add some useful feature or make some other worthy change
that is impossible or impractical/hard without the change?