Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gateway: Test concurrent rinfo for main_thread_only #274

Closed
wants to merge 2 commits into from
Closed

gateway: Test concurrent rinfo for main_thread_only #274

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
af78844
gateway: Test concurrent rinfo for main_thread_only
zmedico Apr 27, 2024
937fb12
[pre-commit.ci] auto fixes from pre-commit.com hooks
pre-commit-ci[bot] Apr 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions testing/test_gateway.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -645,3 +645,45 @@ def test_main_thread_only_concurrent_remote_exec_deadlock(
ch.close()
gw.exit()
gw.join()


def test_concurrent_rinfo(execmodel: gateway_base.ExecModel) -> None:
# Use a temporary Group to force the desired execmodel, since
# groups used by fixtures tend to use the thread execmodel.
group = execnet.Group(execmodel=execmodel.backend)
gw = group.makegateway(f"execmodel={execmodel.backend}//popen")

# For main_thread_only _rinfo will deadlock unless the gateway
# has cached the result earlier, but only if sleep_time
# exceeds the 1 second grace period in the WorkerGateway
# _local_schedulexec method. For other execmodels, a shorter
# sleep_time is sufficient to test concurrent _rinfo.
sleep_time = 1.5 if execmodel.backend == "main_thread_only" else 0.5
try:
if execmodel.backend == "main_thread_only":
# Cache rinfo like pytest-dist does for backward compatibility,
# in order to prevent a deadlock error when pytest-cov requests
# rinfo while the main thread is busy with the pytest-xdist
# WorkerController's remote_exec call.
gw._rinfo()
assert hasattr(gw, "_cache_rinfo")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zmedico I admit I'm a bit confused what the test is testing. What is the failure it is testing against?

If we omit the above gw._rinfo() call then this test case reproduces the underlying issue from pytest-dev/pytest-xdist#1071:

  File "execnet/testing/test_gateway.py", line 682, in test_concurrent_rinfo
    rinfo = gw._rinfo()
            ^^^^^^^^^^^
  File "execnet/src/execnet/gateway.py", line 87, in _rinfo
    self._cache_rinfo = RInfo(ch.receive())
                              ^^^^^^^^^^^^
  File "execnet/src/execnet/gateway_base.py", line 934, in receive
    raise self._getremoteerror() or EOFError()
execnet.gateway_base.RemoteError: concurrent remote_exec would cause deadlock for main_thread_only execmodel

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right but that failure is expected right? And we're testing that adding the extra _rinfo call prevents it from happening?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to provide some test coverage for the scenario that led to pytest-dev/pytest-xdist#1071, since this sort of coverage could have prevented a broken release of pytest-xdist.


ch = gw.remote_exec(
f"""
import os, time
time.sleep({sleep_time})
channel.send(os.getpid())
"""
)
rinfo = gw._rinfo()
try:
res = ch.receive()
finally:
ch.close()
ch.waitclose()

assert res == rinfo.pid
finally:
gw.exit()
gw.join()
group.terminate(0.5)