[Bug 26785] PendingMessagesRemoved signal should be more informative

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=26785





--- Comment #2 from Cosimo Alfarano <cosimo.alfarano at collabora.co.uk>  2010-03-01 07:54:17 PST ---
I ignore the id that I do not recognize, assuming they have been sent before
TPL start up. That's right. In my specific case it works.

I was wondering if a more descriptive data wouldn't be better for the signal's
users, which usually would store and retrieve more information just to
understand to which message the id is related.

Being able to access the message-token, when present, I think would allow
Clients to retrieve less data or in a faster way.

In my case for example, I need query a DB (sqlite by now), which is not the
best in performances, especially on small devices. I cannot use in-memory DBs
because I need persistent data between restarts.
Reducing those queries and/or the size of the stored data would probably help.

This assuming that TP already has a pointer to Message_Part[0] to pass to a
signal and would cost almost 0 to pass it.

I also understand that it's a stable signal and it's not easy to amend it.

Consider also this scenario, which is not my case, but shows a possible race (I
hope I am not missing anything):

An observer wants to keep track of the receiving and ACK times for every
message it can.

- The observer receives a message (Chan1,Id1,Timestamp1).

- The observer restarts. It does not know if it was the observer's service
restarting or the whole TP. TP actually restarted.

- The pending queue after the restart contains some messages, the last one is 
(Chan1, Id1,Timestamp2).

- At Timestamp3, while the observer is analysing the pending queue to check if
(Chan1,Id1,Timestamp1) is in the PM list, a signal for (Chan1,Id1) arrives.

Actually (Chan1,Id1) refers to (Chan1,Id1,Timestamp2), but the Observer does
not know it since it still has to finish the PM list analysis.

- Without the timestamp information for in the signal, the observer wouldn't
know to which message actually (Chan1,Id1) is referring, and in the lack of
information it would probably update the status of (Channel1,Id1,Timestamp1),
which is the message with the most recent timestamp matching (Channel1,Id1)
without ACK, with the information "ACK occurred at Timestamp3".

When the PM list analysis finishes, two erroneous information have been stored:
- the wrong message has been marked as ACK at Timestamp3
- (Channe1,Id1,Timestamp2) won't have any ACK data related to it, unless
another similar race will happen.

Yes, the situation is rare.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.