[GRASS-git] [OSGeo/grass] d1bb79: grass.pygrass: Fix double lock release when stoppi...
Vaclav Petras
noreply at github.com
Tue Sep 29 07:17:12 PDT 2026
Branch: refs/heads/main
Home: https://github.com/OSGeo/grass
Commit: d1bb794733e9b5841caab16ab57a941ae8fecdbd
https://github.com/OSGeo/grass/commit/d1bb794733e9b5841caab16ab57a941ae8fecdbd
Author: Vaclav Petras <wenzeslaus at gmail.com>
Date: 2026-09-29 (Tue, 29 Sep 2026)
Changed paths:
M python/grass/pygrass/rpc/__init__.py
M python/grass/pygrass/rpc/base.py
A python/grass/pygrass/rpc/tests/grass_pygrass_rpc_base_test.py
M python/grass/temporal/c_libraries_interface.py
M python/grass/temporal/core.py
Log Message:
-----------
grass.pygrass: Fix double lock release when stopping RPC servers (#7969)
The forkserver start method test failed intermittently in CI, including
on main, because the RPC servers of grass.pygrass and grass.temporal
released their lock twice.
The handler of the stop message, which the client sends to end the
server process, released the lock inside a with-lock block, so the lock
was released again when the block exited. The client terminated the
server right after sending the message, so the resulting traceback
appeared only when the server handled the message first.
At exit, multiprocessing terminated the servers before grass.temporal
stopped them. The checker thread then restarted a server without a
session, the server failed in G_gisinit(), and its fatal error handler
released a lock it did not hold.
Remove the lock release from the stop and fatal error handlers. Wait
for the server to exit after the stop message before terminating it.
Import multiprocessing.util in grass.temporal before registering its
exit function so that it runs before the exit handler of
multiprocessing. Do not restart a server from the checker thread once
stop was requested, and raise FatalError instead of restarting a server
that multiprocessing terminated at exit, because the restarted server
would never be stopped. Check for this only after the server was found
dead, under the lock, which is race-free because multiprocessing sets
its exiting flag before it terminates the servers.
The failures were identified and the fix written with AI assistance
(Claude Code with Opus 5.5, reviewed by Fable 5.1).
To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications
More information about the grass-commit
mailing list