Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it easy to create Callbacks (or something similar) from lambdas of arbitrary size #520

Open
CodingCanuck opened this issue Aug 4, 2022 · 0 comments

Comments

@CodingCanuck
Copy link
Contributor

An ::eventuals::Callback object can only be constructed with a sufficiently small lambda, which practically means a lambda whose capture contains no more than 2 reference captures (or a total capture size of <= 2 pointers): see #503 for more details on difficulties here.

Let's provide a way to make it easy to construct a Callback regardless of size of the lambda it's being constructed from. Ideally, there should be a way for this to be as painless as constructing a std::function (which can be constructed from any size of lambda, and it transparently chooses whether or not to allocate based on the size of the passed-in lambda: see llvm and gcc code that I think implements small buffer optimization for skipping heap allocation for std::function objects).

Without understanding the constraints of the eventuals type system, maybe there could be something like a hierarchy here: e.g. Callable could be any callable thing (regardless of where's it's allocated). Callback could be an easy to use type that allocates iff needed, like std::function. For the hopefully unusual code authors who are more concerned with optimizing for machine performance at the expense of human performance, authors could construct something like StackCallback or HeapCallback which always allocate on the stack and heap respectively for full control over allocation performance at the host of higher cognitive load when reading the code.

This is coming up a lot in https://github.com/reboot-dev/respect/pull/682 , especially when trying to write unit tests that involve a mock gRPC server, where the lambda handlers used to define the mock's behavior easily need to capture more than 2 variables.

Similarly, we should ensure that the allocation style of a Callback such that something like a Generator<Task<Foo>> can generate tasks without requiring the type signature to change if the generated tasks end up being a mixture of heap and stack allocatede.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant