[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: maphash
From: |
Mattias Engdegård |
Subject: |
Re: maphash |
Date: |
Wed, 11 Sep 2024 16:23:18 +0200 |
10 sep. 2024 kl. 17.52 skrev Helmut Eller <eller.helmut@gmail.com>:
> The documentation states that puthash and remhash are only "allowed" to
> use the current key while a maphash is in progress. (Interestingly, it
> says nothing about gethash.)
That is correct. The purpose of these rules is to avoid us being shackled to a
specific behaviour if a user breaks them; we don't want any more implementation
restrictions than necessary.
We still protect Lisp abstractions so the user shouldn't fear segfaults, but
there are no promises when it comes to the iteration order, whether iteration
will encounter added elements, the same element twice or some none at all, etc.
> However, the code in comp.el uses puthash with other keys. E.g
> comp--add-cond-cstrs-simple iterates over a hashtable of basic blocks
> and while the iteration is in progress, it calls
> comp--add-cond-cstrs-target-block which puts new basic blocks into the
> hashtable.
This sounds like a bug in nativecomp then, even if it happens not to have any
bad consequences right now.
> Should the hashtable implementation detect such situations and perhaps
> signal an error or a warning?
Not unless it can be done at basically no cost. This is not a very common
mistake and letting all correct code pay for it wouldn't be a good trade-off.
- maphash, Helmut Eller, 2024/09/10
- Re: maphash,
Mattias Engdegård <=