Message396740
Oh, it looks like it's because the context for the Event doesn't match when created this way (the default context on linux is fork).
The problem goes away if the Event instance is created from the spawn context -- specifically, patching dump_core.py
```
@@ -22,14 +22,13 @@ def master_func(space:dict) -> None:
if __name__ == "__main__":
- this_event = multiprocessing.Event()
+ context_spawn = multiprocessing.get_context("spawn")
+ this_event = context_spawn.Event()
this_space = dict(
this_event=this_event,
)
- context_spawn = multiprocessing.get_context("spawn")
-
master_proc = context_spawn.Process(
```
I think this can be closed; the incompatibility between contexts is also documented at https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Lock, thought it could be a little more explicit about potential segfaults.
> Note that objects related to one context may not be compatible with processes for a different context. In pait's berticular, locks created using the fork context cannot be passed to processes started using the spawn or forkserver start methods.
(Event uses a Lock under the hood) |
|
Date |
User |
Action |
Args |
2021-06-29 14:48:36 | knl | set | recipients:
+ knl, asvetlov, yselivanov, Andrei Pozolotin |
2021-06-29 14:48:36 | knl | set | messageid: <1624978116.64.0.947048238377.issue43832@roundup.psfhosted.org> |
2021-06-29 14:48:36 | knl | link | issue43832 messages |
2021-06-29 14:48:36 | knl | create | |
|