registerCallback returning Any considered harmful

[thirtytwobits]

In the current design all of the places where we have Any registerCallback(Function&&) inhibit the ability of users to author custom executors and to integrate with various platforms. The primary issue is the method is required to move a node into an opaque container that is then moved into an unknown caller. There is no canonical key available for the implementation of registerCallback to retain. This prohibits filtering callbacks within execution stages based on type and writing event-driven rescheduling of callbacks by platform layers.

We need to modify this design to use a allocation pool instead of Any types so there is only ever a single memory location containing a given callback within a process.

[pavel-kirienko]

The primary issue is the method is required to move a node into an opaque container that is then moved into an unknown caller.

This design was chosen to eliminate the need for pmr allocation in the executor et al.

There is no canonical key available for the implementation of registerCallback to retain. This prohibits filtering callbacks within execution stages based on type and writing event-driven rescheduling of callbacks by platform layers.

I think this could be addressed without compromising on memory management by replacing Any with an ImplementationCell, where the implementation cell offers an interface that enables the client to query relevant properties of the callback. Should we see how such an interface could be designed?

[pavel-kirienko]

I should add that the minimization of dynamic memory allocation (incl. pmr and pools) was one of the core design goals, hence why this design was chosen:

Here, "heap" includes all kinds of dynamic memory, including pmr and pools.

[thirtytwobits]

If you look at #402 you'll see my attempts to attach custom properties to these nodes are thwarted by unknown and mysterious forces lurking in the depths of CAVL.