Clojurians Log v2

Any boot.pod experts here? I'm wondering what the overhead is of evaluating a script in a pod?

When starting a pod it takes 1 or 2 seconds. I'm guessing with a pod-pool this would be less. I didn't figure out how to call a pod from a pod-pool yet

I'm asking because i would like to see if boot.pods could be a viable backend for evaluating closh scripts (https://github.com/dundalek/closh/pull/123)

@jeroenvandijk Im not sure you would gain anything by using a closh script, however if you are simply trying to evaluate clojure code, then pods are exactly what you want

As you mentioned the overhead is a few seconds to start the pod, however you generally keep it running and then reuse it later

@flyboarder Thank you, sounds good. Do you happen to know about an example with a pod pool?

Generally you shouldn’t need the pool unless you are destroying the pods repeatedly, boot pods are created from an internal pool anyway

So the idea is to have one off scripts (closh scripts) that need to be isolated from anything else to prevent conflicts. By using a warmed up pod the script would boot fast. After the execution you probably would want to kill the pod as the goal was to prevent conflicts. Does this make sense?

@jeroenvandijk yes, but unless you run into problems a single pod should suffice for that use case, since you are really just trying to isolate the runtime from the boot project

would running a script again within the same pod cause some kind of state conflict?

even if it did, since the pods come from their own internal pool, you probably dont need to manage that yourself - I think this is an over optimization problem

@flyboarder At the moment it is all hypothetical, but I can imagine one script could (re)define a function and another script would use that version instead of it's own. So maybe it would be safe enough to assure different scripts don't use the same pod concurrently

Thanks for the feedback. I will need to experiment with it to see how it works

@jeroenvandijk I think you are fine just to destroy the pod and create a new one each time the task runs, the internal pool will handle that for you already. If you have serious performance issues then managing your own pool would be the next thing to try

@flyboarder Thank you I'll give it a try