xdoardo
commented
1 week ago Hello, thanks for the proposal. The issue is this: middlewares can change the compilation of a module, and engines take care of doing said compilation, therefore they're inevitably tied. However, I think there's a way to get around that, so we'll get around to do this when we can allocate time for it.
Motivation
Currently, the middleware API supplies two hooks:
Middlewares are also attached to engines (rather than modules or instances).
However, there is no connection between those two. This means that when a middleware encounters a new function, it does not know which module this function belongs to. Since parallel compilation is possible, it's also not possible to assume that the last module initialization belongs to the current function initialization (I guess).
The only middleware currently available is the metering example. In order to cope with this API, the middleware is restricted to handle a single module per engine via runtime check (with a panic).
Proposed solution
Either attach middlewares to modules or instances rather than the whole engine, or supply the module id to the per-function initialization.
Additional context
It would be good to have other middleware examples in order to demonstrate the additional possibilities of this API. Right now this seems only to be good for metering, but maybe I'm missing something.