Using async seems roughly equivalent to scheduling a Continuation. Calling it will likely create a thread or a thread pool, on top of the ones in the ATS core. atscppapi also has a C++ wrapper for TSCont (in Continuation.h). I tried to get in some improvements to this ( https://github.com/apache/trafficserver/pull/4848 ). But the PR got such a cold shoulder, it died of hypothermia. I guess using async is a bypass for our brute-force thing of requiring Continuations to be scheduled with a mutex.
On Tue, Jan 21, 2020 at 11:38 AM David Calavera <david.calav...@gmail.com> wrote: > Hi all, > > I was exprimenting with a new plugin over the weekend with and arrived to a > blocking point, probably because my lack of experience with the async story > in C++. This is the challenge. > > I'm integrating a C++ client that invokes calls asynchronously and returns > objects that implement std::future. I was thinking about creating an > AsyncProvider where the invocation happens in the `run()` method. When I > started to think about the AsyncReceiver I started to question this > approach. These are a few questions that came to my mind: > > - When do I send the dispatch to the AsyncProvider? > - Where do I call `std::future::get` or any other blocking call to wait for > the future response? > - Are these calls going to block the TrafficServer threads completely? > - Should I be using a different TrafficServer API? > > I did not find any examples of using std::futures anywhere, so I thought to > ask the list. I'd really appreciate your feedback. > > Cheers, > David >
