On Wed, 9 Dec 2020 at 10:50, Jean-Claude Beaudoin < jean.claude.beaudoin@gmail.com> wrote:
On Wed, Dec 9, 2020 at 3:59 AM Alessio Stalla alessiostalla@gmail.com wrote:
About multithreading, *all *kinds of redefinition have an impact. If I redefine a widely-used, low-level function, with hundreds of call sites – will each thread immediately call the new one without the bug, or will some still call the old one? Again, imposing a proper order would require protecting each function call with a lock, which is even worse for performance than protecting each slot access.
Isn't "inline/not-inline" doing just what is needed in that area?
I'm talking about non inlined functions, for which the implementation may nevertheless have done type inference or other optimizations that could be invalidated by a redefinition.
Still, we consider function redefinition a key feature of Common Lisp. So,
redefinition of classes is in accordance with the spirit of the language.
Redefinition of function is not "in situ". Why should redefinition of classes have to be so? I am not advocating against class redefinition!
It is. We can redefine a function without having to track and recompile/redefine all uses of that function. In the simple case, it's just updating a pointer. But what if the compiler had performed cross-function optimizations? Or, what if the compiler *couldn't *perform such optimizations because they would have gotten in the way of redefinition? It's not just CLOS to have this issue – it's the whole of Common Lisp.