|
Bugzilla – Full Text Bug Listing |
| Summary: | D-BUS pending calls blocks on poll | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Timo Hoenig <thoenig> |
| Component: | Basesystem | Assignee: | Timo Hoenig <thoenig> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dkukawka, suse-beta |
| Version: | Alpha 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Upstream fix | ||
Created attachment 71101 [details]
Upstream fix
mbuild nouse-thoenig-9 provides D-BUS packages (i386) having the fix applied. dbus-1 submitted to STABLE. Closing. This patch is harmful. I'll investigate whether the fix in D-BUS CVS HEAD can be backported without side-effects. Otherwise this one will be solved post Code 10. Moving to 10.2. Will most likely come along with a version update of D-BUS. D-Bus 0.91 was submitted to STABLE which includes the proper fix. |
There is an issue for pending calls taking very long until getting processed. As there are many applications using pending calls for asynchronous IPC via D-BUS this will definitly hit us. An easy example is starting hal-device-manger. It takes several seconds to pop up. I expect other (so far) unaccountable delays I have seen to be solved by getting rid of this bug. Quote from J5 on the D-BUS list: > I had a eureka moment and finally distilled the python introspect > problem down to a simple C test case. This is the cause of > hal-device-manager taking ages to start up but I am not sure what the > fix would be. > > Basically it happens when you create two pending calls and then block on > the one that you sent last. My best guess is that the second pending > call is starving the data from the socket without actually processing > any of the data it doesn't care about. When be block on the first > pending call there is no data to read over the socket so it blocks for > its specified timeout in poll. When it times out the data is processed > and the correct things happen. Hopefully now that the problem is > identified we can find a solution and package this as part of the test > suite.