| Summary: | support synchronous service exits | ||
|---|---|---|---|
| Product: | dbus | Reporter: | Colin Walters <walters> |
| Component: | core | Assignee: | Havoc Pennington <hp> |
| Status: | RESOLVED DUPLICATE | QA Contact: | John (J5) Palmieri <johnp> |
| Severity: | normal | ||
| Priority: | medium | CC: | bugzilla |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Colin Walters
2009-06-12 11:38:16 UTC
This has come up a few times before. I think you just need to 1) release the name then 2) process the pending queue. The exception is if your app needs an exclusive lock on some resource, like the sound card. In that case, one solution is to have a separate lock: which can be a second bus name, or an fcntl lock, or whatever else. And the starting-up replacement service would wait for this lock before it starts processing the queue. Downsides of doing this with some special feature are: * older dbus wouldn't have it anyway * it complicates bus names and message routing even more, and nobody understands it already Two bus names (one for exclusivity, one for message routing) I'm pretty sure works perfectly and is pretty straightforward. An app needs both names to begin processing the queue, only the "routing" name to receive messages, and only the "lock" name to continue processing messages (the routing name has to be owned to _begin_ processing but the lock name to continue). In your cases: 1) and 2) should both go to the new service instance if the old has dropped the routing name. The old one processes what remains of the queue, then drops lock name. When the new instance gets the lock name, it can begin processing the new messages. 3) should be addressed if the old instance iterates the dbus main loop source until there's nothing to read and no messages left. 3) could maybe be enhanced by a call that just says "close() my connection from the bus side" which would allow a more deterministic way to read everything still in the socket buffer. The bus could only close() once the currently-in-process message is written out in full. However, in practice I think this is mostly hygiene and Correctness, while just iterating the main loop source until it stops and calling close() on the client side probably works OK in practice. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.