Alexey Rybalchenko

No, there isn't. Even if the monitor is not automatically launched, device should not assume one will not be started at a later point, e.g. for debugging. Starting the monitor...

Does it also happen on Linux? I can reproduce a similar situation via sigkilling one device - another will hang on MacOS, but not on Linux. Still investigating if I...

Adding the workaround cure (`BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING` + `BOOST_INTERPROCESS_TIMEOUT_WHEN_LOCKING_DURATION_MS=3000`) does "unhang" the remaining device after 3 seconds (earlier sometimes) with a crash: ``` libc++abi.dylib: terminating with uncaught exception of type boost::interprocess::interprocess_exception: Interprocess...

> I see also some deadlock in: It rings a bell if that is also when a peer is crashed/killed. There are several places where a deadlock can occur in...

I've been playing with `BOOST_INTERPROCESS_ENABLE_TIMEOUT_WHEN_LOCKING`. It adds timeouts for the boost internal shm locks. Then there are also my own locks that I can as well instruct to timeout. But...

Declaring a device as read-only will surely give some assurance that it hasn't corrupted anything if it does crash, although I'm not sure how trustworthy that would be. To allow...

Yes, boost::interprocess allows read only access. It translates to mmap flags.

No, that is not implemented atm. Neither is "read only" in general. I was just saying that it is possible. Does a per-channel flag make sense? If a device has...

I'm saying if you have a device that is allowed to write to shared memory (via any one of the channels), and it crashes, then you cannot assume it didn't...

@fuhlig1 @karabowi Could you check if you see what the issue here is please? Not familiar with what geant3 should be doing. Thanks!