Skip to content
Snippets Groups Projects
  • Nat Goodspeed's avatar
    79a3e391
    DRTVWR-476: Kill LLEventQueue, per-frame LLEventPump::flush() calls. · 79a3e391
    Nat Goodspeed authored
    No one uses LLEventQueue to defer posted events until the next mainloop tick
    -- and with LLCoros moving to Boost.Fiber, cross-coroutine event posting works
    that way anyway, making LLEventQueue pretty unnecessary.
    
    The static RegisterFlush instance in llevents.cpp was used to call
    LLEventPumps::flush() once per mainloop tick, which in turn called flush() on
    every registered LLEventPump. But the only reason for that mechanism was to
    support LLEventQueue. In fact, when LLEventMailDrop overrode its flush()
    method for something quite different, it was startling to find that the new
    flush() override was being called once per frame -- which caused at least one
    fairly mysterious bug. Remove RegisterFlush. Both LLEventPumps::flush() and
    LLEventPump::flush() remain for now, though intended usage is unclear.
    
    Eliminating LLEventQueue means we must at least repurpose
    LLEventPumps::mQueueNames, a map intended to make LLEventPumps::obtain()
    instantiate an LLEventQueue rather than the default LLEventPump. Replace it
    with mFactories, a map from desired instance name to a callable returning
    LLEventPump*. New map initialization syntax plus lambda support allows us to
    populate that map at compile time with little lambdas returning the correct
    subclass instance.
    
    Similarly, LLLeapListener::newpump() used to check the ["type"] entry in the
    LLSD request specifically for "LLEventQueue". Introduce another such map in
    llleaplistener.cpp for potential future extensibility.
    
    Eliminate the LLEventQueue-specific test.
    79a3e391
    History
    DRTVWR-476: Kill LLEventQueue, per-frame LLEventPump::flush() calls.
    Nat Goodspeed authored
    No one uses LLEventQueue to defer posted events until the next mainloop tick
    -- and with LLCoros moving to Boost.Fiber, cross-coroutine event posting works
    that way anyway, making LLEventQueue pretty unnecessary.
    
    The static RegisterFlush instance in llevents.cpp was used to call
    LLEventPumps::flush() once per mainloop tick, which in turn called flush() on
    every registered LLEventPump. But the only reason for that mechanism was to
    support LLEventQueue. In fact, when LLEventMailDrop overrode its flush()
    method for something quite different, it was startling to find that the new
    flush() override was being called once per frame -- which caused at least one
    fairly mysterious bug. Remove RegisterFlush. Both LLEventPumps::flush() and
    LLEventPump::flush() remain for now, though intended usage is unclear.
    
    Eliminating LLEventQueue means we must at least repurpose
    LLEventPumps::mQueueNames, a map intended to make LLEventPumps::obtain()
    instantiate an LLEventQueue rather than the default LLEventPump. Replace it
    with mFactories, a map from desired instance name to a callable returning
    LLEventPump*. New map initialization syntax plus lambda support allows us to
    populate that map at compile time with little lambdas returning the correct
    subclass instance.
    
    Similarly, LLLeapListener::newpump() used to check the ["type"] entry in the
    LLSD request specifically for "LLEventQueue". Introduce another such map in
    llleaplistener.cpp for potential future extensibility.
    
    Eliminate the LLEventQueue-specific test.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.