Thanks Vadim for helping out Michele
Michele excellent work and thanks for posting the dev list.

I agree with Rodric


> Functions with their own builtin proxy (go, swift, rust, and also has
less copying of data at runtime)

For max performance actions would need built in proxies.

For Swift I have being looking into kitura and vapor for this.

For Java I think we kind already have since it’s single JVM for
proxy&function. So any optimization to achieve that fastest init on jvm is
welcome and Param is looking into that.

Init needs to be fast to the point of noop/async from the openwhisk invoker
perspective, then on top is user land on what they want to do on init that
is not to be done on every subsequent run.

—Carlos


On Sun, Mar 11, 2018 at 9:02 AM Rodric Rabbah <rod...@gmail.com> wrote:

> Continuing on my earlier post about the native function interface, and
> following up on the latest changes as suggest by Vadim, i wanted to also
> point out that the /init protocol today is synchronous, whereas to do
> validation on the binary or to exec a new process, it’s worth considering
> an asynchronous handoff.
>
> So one thought is to augment the protocol to allow /init to initiate the
> new binary (load it, exec it) and a /ready to poll which waits for a
> response. This bring you closer to the original prototype where you exec’ed
> the binary.
>
> It also makes for a consistent protocol for a native Functions with their
> own builtin proxy (go, swift, rust, and also has less copying of data at
> runtime), and later can be adapted for a native function like a bash script
> which needs a proxy to relay payloads and results.
> The /init equivalent for the latter is starting the script, and /ready is
> waiting for {openwhisk: 1}.
>
> -r

Reply via email to