|
From: Jan M. <jpm...@gm...> - 2008-04-18 21:09:56
|
hi,
triggered by the recent mailing list activities, i just began to scan
the code of manager.py, and i found this:
def event_dispatch(self):
"""This thread is responsible fore dispatching events"""
# loop dispatching events
while self._running.isSet():
# get/wait for an event
ev = self._event_queue.get()
# if we got None as an event, we are finished
if not ev:
break
# dispatch our events
# first build a list of the functions to execute
callbacks = self._event_callbacks.get(ev.name, [])
callbacks.extend(self._event_callbacks.get('*', [])) # <- !!!
# now execute the functions
for callback in callbacks:
if callback(ev, self):
break
what happens here is that the '*' callback handlers are explicitly added
to the (mutable) list of ev.name handlers.
i haven't tried it but this should lead to problems when unsubscribing a
'*' handler since it still remains an
ev.name handler. i suggest a list addition to prevent manipulation of
the list of ev.name handlers:
[...]
# first build a list of the functions to execute
callbacks = self._event_callbacks.get(ev.name, []) +
self._event_callbacks.get('*', [])
[...]
when i find time (might take a while), i might try and implement some
more of the API in the Manager class for myself.
for instance, for an event/callback driven command 'Action: sippeers', i
would implement a method that yields a set of the 'Event: PeerEntry'
Events to spare a user the trouble of (un)subscribing a callback, making
up ActionIds, etc.
anyone besides me interested in this, both using and reviewing it?
regards, Jan
|