On Tue, 1 Jul 2003 19:01:14 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Jul 2003 13:47:03 +0200 (Romance Daylight Time) Vadim Zeitlin <[EMAIL
> PROTECTED]> wrote:
> > 1. try to find the place from where the headers are being sorted/threaded
> > without locking m_mutexHeaders first
> At least lines 2226 and 2290 in wxFolderView.cpp (indirectly) trigger
> some modifications to the state of the sorting/threading data without
> first locking m_mutexHeader: IsInCache may reset the threading data, and
> SelectInitialMessage actually calls the threading code.
I tried to find a correct locking policy, but failed.
The problem I see is that wxFolderView::SelectInitialMessage() does both
of the following two things:
- It calls back the wxFolderListCtrl through some methods like
SelectNextUnreadAfter() that try to lock the mutex.
This prevents locking the mutex before calling SelectInitialMessage()
from the controler, as the call-backs would try to lock it again.
- It directly calls some code that modifies the threading data
structures. A quite hidden such code is the line
const HeaderInfo *hi = hil[idx];
at the end of SelectInitialMessage.
My understanding is that the MVC pattern is broken here, and either the
view should not call the data-structure modifying code without using a
call-back from the controler, or the entire SelectInitialMessage()
code should be in the controler, not the view.
What do you think?
--
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.
pgp00000.pgp
Description: PGP signature
