I'm forwarding this to the SRFI 246 mailing list, where John intended his message to go, I'm sure.
On Wed, Dec 20, 2023 at 4:23 AM Marc Nieper-Wißkirchen < [email protected]> wrote: > See also my remarks here: > https://srfi-email.schemers.org/srfi-246/msg/23931162/ > > Am Mi., 20. Dez. 2023 um 05:21 Uhr schrieb Marc Feeley (via srfi-247 list) > <[email protected]>: > >> >> > On Dec 19, 2023, at 3:02 PM, John Cowan <[email protected]> wrote: >> > >> > There are two remaining guardian issues: >> > >> > 1) We have two proposals for async operations, Marc F.'s guardian-wait < >> https://srfi-email.schemers.org/srfi-246/msg/23507606/> and Daphne's >> guardian-try-collect < >> https://srfi-email.schemers.org/srfi-246/msg/23847614/>. It's unclear >> if these are completely distinct. Here are the apparent differences: >> > >> > a) -wait suspends the calling thread until there is an object in the >> inaccessible objects group; -try-collect triggers a GC to start with. The >> latter is useful if the GC is not running in its own thread (e.g. there are >> no threads). >> > >> > b) If the accessible objects group is empty, guardian-wait apparently >> waits for an object to be registered (adding it to the accessible objects >> group) and then waits again for it to move to the inaccessible objects >> group; guardian-try-collect returns at once. >> > >> > 2) The other issue is less significant and is orthogonal to 1. In the >> Chez and Guile implementations, a guardian is a procedure called with one >> or two arguments to add an object to the accessible objects group or with >> zero arguments to remove an object from the inaccessible objects group and >> return its representative. In Feeley's proposal, these operations are >> procedures applied to opaque guardian objects. In either case, -unregister >> and -wait/-try-collect are procedures applied to guardian objects. It is >> easy to convert either style to the other. The Chez/Guile style is >> backward compatible; the Feeley style is uniform. >> > >> > Daphne is off-line until next year. Marc, I haven't heard back from >> you on Daphne's proposal. Can you weigh in? Thanks. >> >> I think it is a bad idea to introduce a procedure (i.e. >> guardian-try-collect) that triggers a garbage-collection, even if >> conditional. In typical language implementations with a garbage collector, >> it is often a design goal to make the operation of the garbage collector as >> transparent as possible. You shouldn’t have to know when the garbafe >> collector is run, and the algorithm used (stop the world, incremental, >> parallel, concurrent, etc). A garbage-collection is, relatively speaking, >> an extremely expensive operation because it operates globally on all >> objects in the heap. It can take anywhere from a millisecond (a long time >> on a modern CPU) to several seconds on large heaps. Imagine a concurrent >> program with N threads calling guardian-try-collect on various guardians >> for which no object gets enqueued. This will cause N GCs in rapid >> succession, with no computational progress happening. In the case where at >> least one object gets enqueued there is a possible improvement in >> performance by stopping the GC as soon as the first object gets enqueued, >> but this requires non-trivial changes to the garbage collector (how would >> you modify a parallel garbage collector) and there is no guarantee that the >> object gets enqueued early in the GC cycle. >> >> Marc >> >> >>
