ubuntu-phone team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

> 
>> It is basically up to the developer of the scope to decide how to do
>> that. You will need to block in the Query::run, hold the reference to
>> the Reply pointer, and manage asynchronous calls in the background, via
>> additional threads or event loops.
> 
> Am I correct in understanding that the results show up in the scope each time reply->push is called?  If so, I could probably get nearly the same result by making a series of synchronous requests with pushes in between.  Presumably we'd also need to be checking if cancel had been called anywhere in there.

As Rodney said, you can do anything you like in terms of doing asynchronous work. If you override ScopeBase::run(), you can set up whatever async machinery you want when the scope is first initialized. The run time has no further interest in this thread, that is, it just calls ScopeBase::run() on a separate thread, and you can do with that thread whatever you like. Your only responsibility is to make sure that ScopeBase::run() returns in response to a call to ScopeBase::stop() in a timely manner. That's because the run time will try to join with the run() thread. If your run() implementation does not return within around 4 seconds, the registry will kill the scope process.

The other option is to implement SearchQueryBase::run() such that it keeps a copy of the reply proxy and returns immediately. The query is kept alive by the run time as long as there is at least one copy of the reply proxy still around. Once you drop the last reply proxy, the finished() message goes to the dash.

And, yes, results are pushed immediately and rendered immediately every time you call push(). Note that, because cancellation is frequent, you need to respond promptly to a cancel() message. This is particularly important if you implement run() synchronously, because there is only a single thread in the dispatch pool that calls run(). In other words, the next call to run() cannot start until after the preceding call to run() has completed. If you implement run() asynchronously, you can effectively have multiple queries in flight, so responding to cancel() quickly is less important (but still consumes resources): once the cancel() for a query is received by the scope, the scope-side run time drops all calls to push() for the cancelled query on the floor.

Michi.