|
From: James H. <ja...@al...> - 2023-06-18 08:54:32
|
On Saturday, 17 June 2023 23:05:30 BST Julian Smith wrote: > Apologies if i've misunderstood, but this patch seems a little > questionable - it seems to be hiding a problem rather than trying to > gather information that could be used to fix it. No worries, I'm really not a big fan of it either. > Could you give some more details of the failure mode we are trying to > cope with here? It seems that on certain Mac platforms, the lock is no longer usable after it has been destroyed resulting in exceptions when used by destructing property nodes, presumably like the one Fahim Dalvi quoted yesterday: libc++abi: terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument So yeh its a destructor ordering thing, and it'd be better if the properties were cleaned up first. Given that its not a problem on Linux or I think Windows I figured its best to just make it work in that case. > [If the problem is that properties are being manipulated after the > static global `std::shared_mutex nodeOriginsLock` is being destructed by > the C++ runtime, and for some reason we cannot avoid this happening, > then maybe we could put nodeOriginsLock on the heap and never delete > it, e.g. with `static std::shared_mutex& nodeOriginsLock = *new > std::shared_mutex`?] Sure, that does seem better. I'll give that a try and report back here with a patch for a kind Mac user to test. Thanks James |