Oops, I forgot to start the thread in the above example for
compute_something(), ``th.start()`` should go right after initializing the
thread but before the try-finally block
On Thu, Feb 13, 2020 at 6:15 PM Kyle Stanley wrote:
> > I agree that is counter to the basic philosophy, though there
> I agree that is counter to the basic philosophy, though there are
potential use cases where it may be unavoidable to use threads. It seems
the best solutions when it is then are to use run_in_executor, which
automatically handles the waking up of the loop.
While this doesn't provide an
I agree that is counter to the basic philosophy, though there are potential use
cases where it may be unavoidable to use threads. It seems the best solutions
when it is then are to use run_in_executor, which automatically handles the
waking up of the loop. While the Queue object doesn't work
Sharing futures between threads like that goes counter to asyncio's basic
philosophy (which is not to use threads :-).
You already showed the solution:
future._loop.call_soon_threadsafe(future.set_result, ...). If that's
unacceptable for you, maybe you can wrap the future in a wrapper class that
