bug#33458: 27.0.50; dired loses position when reverted from outside place

[martin rudalics]

> The downside of such an approach is that any buffer-local reference to
> a window will assure that the window object cannot be reclaimed by the
> collector as long as the buffer is live, even when the window is not
> stored in a configuration any more.  Not that I consider this a great
> downside though.

Reconsidering ...

Imagine a scenario where a user (1) displays a buffer in new window,
(2) switches in that window to another buffer and (3) deletes that
window for good.  When and how would the buffer-local reference
created in (2) be removed?

It can't be done in (3) since a window configuration stored somewhere
might still need it.  But if there is no such configuration, it should
be eventually removed since otherwise such references may pile up and
inhibit reclamation of all associated window objects.  Unfortunately,
there's no way to find out if such a configuration exists.  Obviously,
when the buffer gets eventually killed, its local variables get killed
too and the reference will vanish.  But in a long session many buffers
may be kept around for a long time and every time the above scenario
repeats itself a new reference will be added.

The only way to solve this dilemma I can see is using the collector.
For this, any reference created in a step like (2) would have to be
considered weak, that is, would not be be marked from the buffer-local
list.  When the collector sweeps buffers, it would have to perform an
extra check on that list: If the corresponding window was not marked
so far, it would be considered definitely dead, the reference get
removed from that list and the window be reclaimed in the subsequent
vector sweep.

As if things were not already complicated enough, any access to that
list (needed when reverting a buffer to update the point position for
every window showing the buffer in the past) would then have to be
atomic (not allocating) to avoid that the collector reclaims a window
under the feet of such an update operation.

Finally, this would not help wrt window states because these do not
care about window objects in the first place.  So I think that
implementing a scheme based on buffer-local window references is
hardly feasible.

Admittedly, GC should do something similar when sweeping window
configurations since these may still hold references to killed buffer
objects and thus prevent their reclamation.  But that would be fairly
simple since a buffer that has been killed will remain killed forever.
OTOH, a window that has been deleted may remain in a zombie-like state
until the last configuration referencing it has been removed.

martin