Should the bus be able to deliver OOM on replies?
Fri Mar 12 02:15:13 PST 2004
On Thu, 2004-03-11 at 19:00, Richard Hult wrote:
> In order to beef up the bus tests, I added to the message dispatch test
> to make it send an Echo method and check for a reply.
> After sending the Echo message, the client occasionally gets no reply
> back from the bus, due to OOM failures. I'm wondering whether the bus
> should be able to reply with an OOM error
This could be done easily enough by adding a preallocated OOM reply to
BusPendingReply, at some efficiency cost. I don't think we should do
this though, see below.
> or if a reply could
> (correctly) be lost in those cases, leaving it to the client side in all
> cases to generate a synthetic timeout, instead of getting an OOM error
> from the bus.
This is a pretty ugly case, since the method call has in fact been
processed, it's just that there's no memory to return the results over
I'm not sure there's a right thing to do so we may as well do the simple
thing, let the client side just time out. If the server side wanted to
retry sending the reply it could, though I don't imagine any real app
> Either way, I think we probably need a variant of the test utility
> function block_connection_until_message_from_bus() that times out,
> otherwise the tests will just hang when that happens.
Yep, with the danger that it could conceal genuine bugs... there are
lots of bugs that could cause a lack of reply. Maybe some hack to set a
"reply isn't going to come" flag on the server side when it gets this
specific OOM - that would also speed the tests up by avoiding the
More information about the dbus