Extism continues to be a delight to work with.

I realized that Extism probably has limited support for automatic concurrency, especially when calling host functions or the HTTP API. I verified that invoking the same plugin in parallel blows up. Of course I thought to check the FAQ after that: https://extism.org/docs/questions#how-does-concurrency-work-are-plug-ins-single-threaded

I don't need concurrency right away, but definitely will, so I want to be sure I understand the constraints.

Basically my current plugin design works as an HTTP handler. Requests com in, Responses go out. My plugin also does KV operations via host functions, and makes outgoing HTTP requests (which I'm assuming is essentially implemented like a host function). I need to be able to run the plugin from many concurrent incoming HTTP requests.

In golang, a simple design would be a pool of worker goroutines listening on the same channel. Each goroutine has it's own plugin instance. In a loop, each worker pulls a job off a go channel, invokes the plugin, then sends the result on a separate channel (probably one passed in the first channel). Basic actor arrangement.

So, a few questions:

• It sounds like I need to have 1 plugin instance per concurrent execution. Is that correct?
• On what order is the overhead of plugin instances? Goroutines are very cheap. It wouldn't be a problem to have 100s of worker goroutines. I could probably make it pretty far with ~4 plugin instances, but it would be nice if I don't need to worry about it.
• How much overhead is there to instantiating a new plugin? I doubt it but maybe I could just do that for every request?
• I'm confident about implementing this in Golang, but less certain about other languages like JS and Python. In JS maybe a ReadableStream worker queue? Any tips or gotchas I should look out for?