This can be used when the key is name spaced, e.g. `/foo/bar` or `foo.bar`. Here we can erase everything under foo by using `/foo/` or `foo.` respectively.
This was previously done because the function wasn’t available until 10.7, but since that is (now) our deployment target, there is no need to wrap the call.
This makes the abstraction redundant and it should be removed. I am doing that as a multi-step process, since the previous implementation was blocking tests from being updated to the new (dispatch queue based) test system.
The mutex was locked to ensure that the client object did not go away, but the client’s code may terminate the program which destroys the server_t instance and thereby the mutex itself, which would previously cause an assertion to trigger, since the mutex was locked during destruction.
In practice there is no issue with the mutex not being locked while accessing the client object, as “unregister_client” and “master_run” are both called from the main thread, except for tests, but here we do not unregister client objects before their requests have been handled.
The “proper” replacement for this API is to use the ServiceManagement framework’s SMJobBless() to bless our helper tool. In two of the three use-cases our helper tool is however regular shell commands, so it seems redundant to wrap these shell tools as helper tools we can install as launchd jobs.
We need this in a few places and while calling Gestalt() isn’t that much code, that function is deprecated in 10.8 and the alternative is a lot more code, so we don’t want to repeat that once we update the code.
20% of reported crashes are in launch_tbz which indirectly call oak::c_array. My hunch is that the c_str buffer is overwritten because the std::string which returned it has been disposed, this makes strdup() do a bad allocation / memory read.
This would likely be a race condition (wrt. the c_str buffer) and coincidentally the oak::c_array is called in a thread (when it crashes).
