[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54532: [PATCH] sorting
From: |
Mattias Engdegård |
Subject: |
bug#54532: [PATCH] sorting |
Date: |
Thu, 24 Mar 2022 10:55:03 +0100 |
24 mars 2022 kl. 10.17 skrev Andrew Cohen <acohen@ust.hk>:
> 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.
bug#54532: [PATCH] sorting, Lars Ingebrigtsen, 2022/03/31