You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some circumstances, initializing time for a lambda could be quite large. it would be great to be able to configure some lambdas with a configurable number of pre-provisionned processes.
Once a lambda is pre-provisionned, it is started unconditionally in a pool. The lambda can then initialize all it wants and once initialized will stop waiting on I/O (stdin and stdout). Upon invocation, one lambda from the pool would be used and the standard input will be written to and standard output will be read to, motioning the lambda forward. Once a lambda from the pool is taken, a new lambda would be started to refill the pool.
edit: This is incompatible with MethodEnv, PathEnv, InputHeaders and Query.
Implementation could be:
in lambda interface add Start() and Stop() functions that notifies when the lambda is made available and the lambda is destroyed.
Start() should run a specialized invoke function where stdin and stdout are pipes. The other end of pipes should be stored in a pool data structure as well as a context cancel function (for lambda timeout)
Invoke() should either take a running lambda from the pool and connect the pipes (io.Copy for that), ensure the cancel function is called at the timeout event, or if there is nothing on the pool, should invoke a new lambda instance
Stop() should cancel all running lambda instances in the pool
When updating the lambda manifest SetManifest() and reloadManifest() the pool should be adjusted
The text was updated successfully, but these errors were encountered:
My use case is to have lambdas that do some backend tasks and I have currently no use for lambdas that can respond to any HTTP request, but it feels bad not to have lambdas able to access HTTP headers, path and query. Could there be a way to allow lambdas to read this information through a side-channel ?
I'm thinking that perhaps an environment variable could reference a filename that would contain all this information (in JSON for example). This file could be a pipe too and unblock reads to it when the actual request arrives.
I was also thinking that perhaps a lambda could avoir exiting and be reused, probably only a limited number of times, but this would require signaling when the stdin/stdout is finished for the current request, incpmpaticle with the current way to do things. Perhaps this is not really important.
In some circumstances, initializing time for a lambda could be quite large. it would be great to be able to configure some lambdas with a configurable number of pre-provisionned processes.
Once a lambda is pre-provisionned, it is started unconditionally in a pool. The lambda can then initialize all it wants and once initialized will stop waiting on I/O (stdin and stdout). Upon invocation, one lambda from the pool would be used and the standard input will be written to and standard output will be read to, motioning the lambda forward. Once a lambda from the pool is taken, a new lambda would be started to refill the pool.
edit: This is incompatible with MethodEnv, PathEnv, InputHeaders and Query.
Implementation could be:
Start()
andStop()
functions that notifies when the lambda is made available and the lambda is destroyed.Start()
should probably be called intrusted-cgi/application/platform/platform.go
Line 211 in c76c262
Stop()
should be probably called fromtrusted-cgi/application/platform/platform.go
Line 180 in c76c262
Start()
should run a specialized invoke function where stdin and stdout are pipes. The other end of pipes should be stored in a pool data structure as well as a context cancel function (for lambda timeout)Invoke()
should either take a running lambda from the pool and connect the pipes (io.Copy for that), ensure the cancel function is called at the timeout event, or if there is nothing on the pool, should invoke a new lambda instanceStop()
should cancel all running lambda instances in the poolSetManifest()
andreloadManifest()
the pool should be adjustedThe text was updated successfully, but these errors were encountered: