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

Allow to pre-provision lambdas #30

Open
mildred opened this issue Apr 30, 2024 · 3 comments
Open

Allow to pre-provision lambdas #30

mildred opened this issue Apr 30, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@mildred
Copy link

mildred commented Apr 30, 2024

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 probably be called in
    func (platform *platform) setupLambda(lambda application.Lambda) error {
  • Stop() should be probably called from
    func (platform *platform) Remove(uid string) {
  • 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
@reddec reddec added the enhancement New feature or request label May 2, 2024
@mildred
Copy link
Author

mildred commented May 2, 2024

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.

@reddec
Copy link
Owner

reddec commented May 3, 2024

@mildred thanks for the proposal ❤️!
For the headers you may set mapping in https://trusted-cgi.reddec.net/usage/manifest/

@BasToTheMax
Copy link

Yeah. This feature would be nice.

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

No branches or pull requests

3 participants