Yes, fair point, although this functionality is really easy to layer on top so, arguably, not leveldb's job. But what is annoying is that, when the DB is locked, no unique error code is returned for the condition. Instead, the fact that the DB is locked gets lumped into the same status code that is used to indicate dozens of other problems. Sigh… When will people learn that it is necessary for the calling code to tell different error conditions apart without having to parse the text in the error string? :-(
I think I'll just use a lock file of our own around the initialisation/finalization. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1511553 Title: Crash in queueRequest Status in thumbnailer package in Ubuntu: Confirmed Bug description: https://errors.ubuntu.com/problem/fa22f0b18ff6dc949c4cdf768f32121d64a83b8d We hit this occasionally, but not very often. I suspect it is because of the way we shut down: we destroy the thumbnailer instance before the dbus interface so we don't hit the race condition where one instance of the service still has the database lock while a second instance of the service is activated by a new incoming request. But, destroying the thumbnailer first means that, if a request arrives at just the right time, the dbu sinterface fires the request at the already-destroyed thumbnailer. I recently hit a whole slew of issues in a test that destroyed the thumbnailer and dbus interface (in that order) while there were still requests sitting in the scheduler and thread pools, and fixed a bunch of these issues (see the request-cancellation branch.) In effect, via the handler class that calls back into the thumbnailer and the closures that sit in the thread pools, we have created a circular dependency between the dbus interface and thumbnailer, which makes it impossible to shut down either without causing problems. I think the best solution would be to add a shutdown() method to the dbus interface that prevents new requests from firing. We also need some way to wait for all *received* (not just scheduled) requests to finish executing before physically shutting down. Does DBus have a way to say "I'm in the process of shutting down. Send the request that just arrived and that I can't process anymore to a new instance of the service"? Ideally, I would like to "close the gate" on incoming requests such that they are transparently re-sent, and then wait for all currently executing requests to finish processing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thumbnailer/+bug/1511553/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
