compatibility issue when asyncio loop policy is not the default one about arsenic HOT 7 CLOSED

Interesting... any idea what's actually blocking?
Is it trying to spawn geckodriver?
Or trying to connect to its port?
Or is it the .get(...) operation, which, in essence is aiohttp request?

from arsenic.

I do not see any geckodriver process and I just noticed the python process uses 100% of a CPU while blocking on get_session.

from arsenic.

It block when checking the version of geckodriver, here is the call stack:

run_process (.../venv/lib/python3.9/site-packages/arsenic/subprocess.py:46)
_check_version (.../venv/lib/python3.9/site-packages/arsenic/services.py:73)
start (.../venv/lib/python3.9/site-packages/arsenic/services.py:92)
start_session (.../venv/lib/python3.9/site-packages/arsenic/__init__.py:28)
__aenter__ (.../venv/lib/python3.9/site-packages/arsenic/__init__.py:16)
main (.../test.py:18)
_run (/usr/lib/python3.9/asyncio/events.py:80)
_run_once (/usr/lib/python3.9/asyncio/base_events.py:1882)
run_forever (/usr/lib/python3.9/asyncio/base_events.py:596)
run_until_complete (/usr/lib/python3.9/asyncio/base_events.py:629)
run (/usr/lib/python3.9/asyncio/runners.py:44)
<module> (.../test.py:24)

from arsenic.

https://github.com/HDE/arsenic/blob/7323c550a46b94aa0dcda6659b9c3eff11bec3f0/src/arsenic/subprocess.py#L46
code in question...

I wonder if asyncio.create_subprocess_exec and process.communicate are supported in this custom event loop 🤔

from arsenic.

It could be smth like jhenstridge/asyncio-glib#5 🤔

from arsenic.

Given that the last update to asyncio_glib was almost 2 years ago, I'm tempted to point my finger there.

from arsenic.

Indeed, I will try something else for glib event loop interaction. Thanks for looking into this.

from arsenic.