On Wed, Apr 4, 2018 at 10:16 PM, Julien Salort <lis...@salort.eu> wrote:
> In this case, the script spends most of its time waiting for a frame to be
> available on the cameras, and the time interval to query the other device.
> The fetching and processing of the frames take negligible time. The library
> that I use is not asynchronous, but it was very easy to run_in_executor the
> C function that blocks until a frame is available on a given camera.
>
> Compared to a non-async version where I would have had to use that C
> function with some short timeout and iterate over all cameras, I think the
> async version is more efficient. The await will just be as long as it takes
> for the WaitFrame C function to run... When the C function ends, the
> asynchronous task resumes... There is no need to adjust some timeout by
> hand.
Can you give an example? Let's say we have a simple blocking C function:
int get_data() {
sleep(2);
return 42;
}
How do you use run_in_executor to turn this asynchronous, and how
would this compare to creating one thread for each camera? AIUI,
run_in_executor uses a thread pool under the surface, so all you're
doing is using threads via an asyncio interface. Comparing to a
timeout implementation is unfair; a threaded implementation is more
comparable.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
