go-jsonnet -- evaluate while respecting context?

[Rudolf Thomas]

Hello,


We'd like to put a deadline on evaluating (user-supplied) Jsonnet code
in our Go server.

As of v0.20.0, the best bet seems to be to exec the jsonnet binary with
a deadline set up in a Context.


I've come up with an idiomatic way to do this -- add Context-aware
evaluation functions to the go-jsonnet library.

See the PR at https://github.com/google/go-jsonnet/pull/615 FWIW, it got
a few thumbs-ups :)


My question for the group: Is evaluation within a wall-clock Deadline
something that the library should support?

If the answer is yes, could someone please look at the PR? If not, what
other ways do we have to achieve this, other than executing the jsonnet
binary?


Thanks.


Rudo

[Dave Cunningham]

This is in general very hard to do without introducing subtle bugs.  For example, when someone introduces an optimisation that means there is no-longer O(1) work between context checks, or for native libraries or I/O.  Even if you track time, what about memory use, or other OS resources like file handles.  That is why it is generally better to sandbox things via a subprocess because it's a much smaller footprint and it can be solved "once and for all".  What is the problem with using a subprocess?

--
You received this message because you are subscribed to the Google Groups "Jsonnet" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsonnet+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jsonnet/ac84f86f-3691-af88-e3ad-2cad7ae5135f%40firma.seznam.cz.

[Rudolf Thomas]

Thanks for the feedback.

You are right that time is not the only resource one might want to limit. In our specific case, we ourselves are the "user" who supplies the code to evaluate, so tracking just the wall time seemed enough of a sandbox.

There is no problem as such with a subprocess, the main reason to use the in-process interpreter is the convenience of the implementation in Go. We don't use imports in this case, so I can't even claim that we could benefit from caching between runs... :)

I guess the risk of introducing the subtle bugs plus the limitation of only tracking time is not worth trying to get the PR merged (possibly with more work and/or documenting the caveats). What do you think?

Cheers.

Rudo.