Bugzilla – Bug 9244
Make it possible to identify the source of requests
Last modified: 2009-09-08 09:18:55 UTC
Created attachment 3853 [details] Old patch providing one possible solution It would be really useful if all requests had an identifiable source. The alarm code would benefit greatly from this as it needs to be able to filter out stop/pause notifications that occur as side effects of the alarm (e.g. synced players etc). One approach would be to automatically fill in the request's source attribute when it's not already present. Triode provided a quick patch that would do this - see attachment. The impact on performance for doing it this way is unknown, however. If filling in all request sources is impractical, it should at least be possible for the originator to specify it. At the moment, notifyFromArray does not allow this. This caused problems with the new sync code as it notifies events using notifyFromArray and there was no way to filter them out in the Alarm code. The end result was that all alarms ended almost straight away due to receiving a stop notification. This issue will almost certainly occur again when the new streaming code is merged (in 7.3?).
cc'ing Triode. Alan speculates that this is needed to determine if a request is a confirmation of something that was triggered by a specific piece of code. Dean speculates that this should maybe be solved by having more expressive messages like 'stop alarm' instead of just 'stop'. Several people note that the use of backtraces in the patch should be avoided. Alan notes we could try to be smarter about when we send out stop notifications. Alan to talk to Max about his exact needs.
My original patch for Max just set the source to the caller() for internally generated events. The alternative is we pass a string indicating the caller - need to look at ther performance hit of using caller()
Alarms are generally stopped on user activity that causes the music to stop and so the alarm code reacts to "stop", "power" etc events. However, it needs to be able to filter out events that it generated itself - e.g. by turning on the player and starting music when an alarm sounds. It also needs to ignore events that happen as side-effects of an alarm going off. For example if the alarm sound is random mix, then random mix itself generates stop and play events that must be ignored. I've currently handled this by modify the alarm code and random mix to always set the source of events to a known string. However, this doesn't scale to unknown sources such as 3rd party plugins or, as happened before, new core code sending out events, such as the new sync code. What's really needed, I suppose, is for events to have some sort of "don't affect the alarm" tag. However, I'm not at all sure about the practicality of this.
I think setting $request->source for your own executes is probably the best way of achieving this (as done by Alarm already). The patch or the ability to pass a label to notifyFromArray and executeRequest would make this happen automatically for all requests/notifies, but other than telling you its someone other than ALARM doing it, there is no real additional information here - you would still need to check what it is set to in the alarm code. So in summary - can we live with what we have at present?