// sort array elements using passed comparaison function
void wxArrayString::Sort(CompareFunction compareFunction)
{
START_SORT();
wxASSERT( !gs_compareFunction ); // must have been reset to NULL
gs_compareFunction = compareFunction;
DoSort();
// reset it to NULL so that Sort(bool) will work the next time
gs_compareFunction = NULL;
END_SORT();
}
The START/END_SORT macros are the issue here. START_SORT looks like
this when wxUSE_THREADS is defined:
#define START_SORT() wxASSERT( !gs_critsectStringSort );
\
gs_critsectStringSort = new
wxCriticalSection; \
gs_critsectStringSort->Enter()
In debug the assert on gs_critsectStringSort fires off and when i check
it gs_critsectStringSort is always null. The reason is that
gs_critsectStringSort was changed between the time the assert was
caught and the debugger break'd.
The flaw here seems obvious to me, but i have to think i'm missing
something. gs_critsectStringSort protects the sort... but what
protects gs_critsectStringSort from another thread creating a new
wxCriticalSection? Nothing that i can see.
So am i right or am i missing something?
> So please someone correct me if i'm wrong about this. I believe my
> foreground thread is screwing up sorts occurring in one of my worker
> threads. wxArraySort looks like this...
...
> The flaw here seems obvious to me, but i have to think i'm missing
> something. gs_critsectStringSort protects the sort... but what
> protects gs_critsectStringSort from another thread creating a new
> wxCriticalSection? Nothing that i can see.
You're right, there is really a bug here, the critical section should be a
global. Fixed in the cvs, thanks.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
For additional commands, e-mail: wx-use...@lists.wxwidgets.org