Open Buratti opened 3 weeks ago
@swift-server-bot test this please
@fabianfett wdyt ?
@swift-server-bot test this please
@adam-fowler if time permits, can you have a look at this PR please ?
I'm inclined to not support this change. For a couple of reasons:
ByteBufferAllocator
provides. Given that ByteBufferAllocator currently does not have some magic buffer reuse tactics, I doubt that this will yield any benefit.I want to point out that the correct NIO pattern here would be to forward the ByteBufferAllocator
from the channel's ChannelContext
to the user and not one that got allocated once.
No doubt is the current API weird and we are looking into improving it.
I don't see how this change would negatively impact the API surface. The LambdaRuntime class isn't meant for standard development (where you usually interact with a *LambdaHandler
type), it is offered as part of the public API as a way to develop high-level frameworks on top of the runtime. As such, I would argue that the more "configurable" this type is, the better it becomes when it comes to develop a framework on top of it.
It is true that there isn't any performance benefit from this yet. Nonetheless, NIO's best practices suggest to reuse the allocators as much as possible, as the "magic buffer reuse" should be available eventually.
I wasn't aware of the fact that NIO is meant to become an internal import
in the future, in such case, I agree with not supporting this change.
Allow the runtime's
ByteBufferAllocator
to be shared with other systems which are initialized before the handler is instantiated.Motivation:
LambdaRuntimeFactory.makeRuntime
is intended for scenarios requiring high customizability. It's reasonable to assume that these scenarios typically involve other subsystems, which might be initialized beforeLambdaRuntimeHandler.init(context:)
.The simplest example is a structured
swift-log
LogHandler
, where logs are formatted and encoded intoByteBuffers
. In this case,LoggingSystem.bootstrap
needs to run beforeLambdaRuntimeFactory.makeRuntime
, directly inside the@main
entry point, and not inside theLambdaRuntimeHandler.init(context:)
initializer.Modifications:
The private
allocator
ofLambdaRunner
is now injected through its initializer. All themakeRuntime
methods take aByteBufferAllocator
parameter which defaults to a freshly initialized one if left unspecified. This prevents any breaking changes.Result: