SL-18721: Faster viewer shutdown time since performance improvements can lead to perceived inventory loss due to cache corruption#110
Conversation
10f6c40 to
5cbbfba
Compare
…can lead to perceived inventory loss due to cache corruption
|
|
||
| // Special workflow for LLWindowWin32Thread - it's close() should be called explicitly | ||
| if (mExplicitShutdown) | ||
| return; |
There was a problem hiding this comment.
What issues close() call in such case?
There was a problem hiding this comment.
What issues close() call in such case?
As iit was said in the comment above, the destructor of the class ThreadPool calls this method in any case:
LL::ThreadPool::~ThreadPool()
{
close();
}
nat-goodspeed
left a comment
There was a problem hiding this comment.
I understand that you're deferring the LLWindowWin32Thread::close() call to its destructor, and that it's explicitly destroyed by ~LLWindowWin32(). But I don't know where the LLWindow subclass is destroyed?
The class The method The method The full callstack looks as follows: |
nat-goodspeed
left a comment
There was a problem hiding this comment.
Thank you. I thought we'd need a new call at shutdown time, but your answer addresses my concern.
Make
LLWindowWin32::LLWindowWin32Thread::close()to be called from the class destructor