summaryrefslogtreecommitdiff
path: root/indra/llmessage
diff options
context:
space:
mode:
authorNat Goodspeed <nat@lindenlab.com>2015-05-22 22:05:16 -0400
committerNat Goodspeed <nat@lindenlab.com>2015-05-22 22:05:16 -0400
commitdf3da846243cce973468b15d1f1752db2009d4ba (patch)
tree4436a87239d418a27adc25506e684fa6f5793124 /indra/llmessage
parent331e932857e1156a68b6d39d3ea2d8c1f39ec7ae (diff)
MAINT-5232: Add LLPounceable template for delayed registrations.
LLMuteList, an LLSingleton, overrides its getInstance() method to intercept control every time a consumer wants LLMuteList. This "polling" is to notice when gMessageSystem becomes non-NULL, and register a couple callbacks on it. Unfortunately there are a couple ways to request the LLMuteList instance without specifically calling the subclass getInstance(), which would bypass that logic. Moreover, the polling feels a bit dubious to start with. LLPounceable<T*> presents an idiom in which you can callWhenReady(callable) on the LLPounceable instance. If the T* is already non-NULL, it calls the callable immediately; otherwise it enqueues it for when the T* is set non-NULL. (This lets you "pounce" on the T* as soon as it becomes available, hence the name.) So if gMessageSystem were an LLPounceable<LLMessageSystem*>, LLMuteList's constructor could simply call gMessageSystem.callWhenReady() and relax: the callbacks would be registered either on LLMuteList construction or LLMessageSystem initialization, whichever comes later. LLPounceable comes with its very own set of unit tests. However, as of this commit it is not yet used in actual viewer code.
Diffstat (limited to 'indra/llmessage')
0 files changed, 0 insertions, 0 deletions