proxy-wasm-cpp-host icon indicating copy to clipboard operation
proxy-wasm-cpp-host copied to clipboard

Add a one-shot inter-thread notification mechanism

Open gbrail opened this issue 5 years ago • 0 comments

(Not sure what repo to put this idea in...)

I'd like to be able to use a singleton module to store and atomically handle shared state for the filters running on all the Envoy threads. Ideally, it'd be great to support a way to send a "request" to a singleton WASM module running as a bootstrap service, and get a reply. Basically, it's an inter-thread RPC for WASM modules.

This works today (or it will with PR #36 fixed) with the existing queues. For instance, in a filter's "on_http_request" method, we could dequeue from a queue with a unique name that's specific to that thread. This is fine as long as the thread is only ever processing one request at a time, but it's not. So, each thread needs a pool of queues, or some other mechanism to prevent response swapping, and now things are starting to get complicated.

A nicer way to solve this might be using either a "temporary queue," or some sort of one-shot "wait for reply" method. The idea would work something like this:

  1. WASM service (running as a singleton using the bootstrap extensions) registers a queue
  2. In the filter's proxy_on_ method, register the temporary queue or reply thing, and get back an ID
  3. The filter sends a message to the WASM service that includes the temporary queue ID
  4. When the WASM service is done it enqueues its response using the temporary ID
  5. The filter can be notified using the existing on_queue_ready callback, or some new one

The actual mechanism could just be one new ABI:

proxy_register_temporary_queue(name) -> token

The resulting queue would be automatically deleted when the context exits.

The following is even more explicit but it's pretty clean:

// Get a unique token where a reply can be delivered by any thread proxy_register_reply_slot() -> token // Put data in the reply slot and notify the context that created it proxy_deliver_reply(token, data) // Called to let the context know that a reply is available proxy_on_reply_available(context_id, token)

Does anyone else need to solve this problem? Let me know. Thanks!

gbrail avatar Jul 24 '20 23:07 gbrail