Hrvoje Nikšić added the comment:
I would definitely not propose or condone sacrificing performance.
Part of the reason why I suggested the check is that it can be done efficiently
- it is literally a comparison of two integers, both of which are obtained
trivially. I would hope that it doesn'
Andrew Svetlov added the comment:
Heh, should we sacrifice performance?
Documentation for asyncio explicitly states that the only safe interthreading
call is `call_soon_threadsafe()`.
If people use multithreaded environments with asyncio (Why? Usually
`run_in_executor()` doesn't require commu
Yury Selivanov added the comment:
Echo server is usually a good enough microbenchmark (you can use benchmarks
from uvloop/examples). Repeatedly calling call_soon would also be an
interesting micro-benchmark but less important (unless it shows that call_soon
is 2x slower or something).
-
Hrvoje Nikšić added the comment:
> I'd be OK with this if the performance penalty is within 0.5% in
> microbenchmarks for asyncio & uvloop.
@yselivanov Are you referring to specific microbenchmarks published somewhere,
or the general "echo server" style microbenchmarks?
--
_
Yury Selivanov added the comment:
> I suggest that asyncio should be stricter about this error and that methods
> and functions that operate on the event loop, such as call_soon, call_later,
> create_task, ensure_future, and close, should all call _check_thread() even
> when not in debug mode
New submission from Hrvoje Nikšić :
Looking at StackOverflow's python-asyncio tag[1], it appears that it's a very
common mistake for users to invoke asyncio functions or methods from a thread
other than the event loop thread. In some cases this happens because the user
is careless with threads
