Bug 100062 - dbus_connection_read_write_dispatch() may ignore specified timeout value
Summary: dbus_connection_read_write_dispatch() may ignore specified timeout value
Status: RESOLVED NOTABUG
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: git master
Hardware: All All
: medium normal
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-04 18:19 UTC by Rob Norris
Modified: 2017-03-06 23:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Rob Norris 2017-03-04 18:19:20 UTC
in dbus-connection.c:

_dbus_connection_read_write_dispatch() may call _dbus_memory_pause_based_on_timeout()

At (currently line 2182) the final else branch option uses a fixed timeout value of 1000.

Presumably this is meant to be the timeout_milliseconds value passed in (which has been set by the client using the dbus API)?
Comment 1 Philip Withnall 2017-03-06 09:21:48 UTC
_dbus_memory_pause_based_on_timeout() looks like it’s designed to be called with an ever-decreasing timeout, as the difference between the desired timeout and the elapsed time for a particular operation. It clamps the time it sleeps to 1s, so it ends up polling for new memory at 1s intervals (at most).

When _dbus_connection_read_write() and _dbus_connection_read_write_dispatch() call it, they are not calling it in a loop with a decreasing timeout; so they’re at fault here. Although they are documented as using their timeout parameter as a ‘maximum timeout’, so their behaviour does match the documentation.

Is this breaking a use case you have?
Comment 2 Rob Norris 2017-03-06 21:51:09 UTC
I have no particular use case, just investigating some behaviour of gpsd clients that can use dbus.

It just appeared that the code in _dbus_memory_pause_based_on_timeout() looked intuitively wrong, and like a copy and paste error.

So yes it can be for enforcing an upper value, and since it is just for memory allocation that's probably sensible behaviour.
Comment 3 Philip Withnall 2017-03-06 23:30:02 UTC
Let’s close it then. Thanks for looking at this.


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.