Subject: bug#54532: [PATCH] sorting

From: Mattias Engdegård <[email-masked]>
Date: Thu, 24 Mar 2022 10:55:03 +0100

24 mars 2022 kl. 10.17 skrev Andrew Cohen <[email-masked]>:

> No, I think they only get marked during the marking phase of a
> GC. Mattias' implementation simply adds a callback to do the actual marking
> that is invoked in mark_specpdl:
> 
> case SPECPDL_UNWIND_PTR:
> if (pdl->unwind_ptr.mark)
>   pdl->unwind_ptr.mark (pdl->unwind_ptr.arg);
> break;

Right -- it's really just a generalisation of the existing `record_unwind_protect_ptr` and fills a gap that wasn't properly handled before. The other unwind handlers in the family already take care of marking:

record_unwind_protect:
  takes a single Lisp_Object, which is marked.
record_unwind_protect_array:
  takes a heap-allocated array of Lisp_Objects, which are all marked.
record_unwind_protect_int:
  takes an int, which does not need marking.

and so on. `record_unwind_protect_ptr` stands out because it takes a generic pointer and unwind function, but does not account for the possibility that anything referred to by that pointer may need marking. `record_unwind_protect_ptr_mark` plugs that hole in a very natural way.

I don't think we should disable the GC during sorting; the predicate function is not restricted in what it can do. It could build data structures, throw, call sort on another sequence, switch threads, and so on.