in
TIME_TimersList and ..->lpNext instead of referencing them or should it be changed to make
sure
TIME_MMTimeStart and TIME_MMTimeStop etc.. use critical sections.
it's hard to imagine having just the right magic timing conditions and then also having a context switch occur during the short tight loops.
I guess that's a long way of saying that yes, I think you have identified a flaw in the code, but that I can't imagine any way it's could cause the problem you're seeing.
Well, I've managed to reproduce the fault once with the debugger running.. the backtrace I get is
TIME_MMSysTimeThread(arg=0x403ebcb8) winmm/time.c:249 THREAD_Start (ptr=0x40411f00) kernel/thread.c:107 start_thread (info=0x40411f20) ntdll/thread.c:200 libpthread.so.0 (0x4a8f8b2c) ?? +0x5a in libc.so.6 (0x00000000)
But that's not really useful, I couldn't find out how to switch threads in winedbg so I don't known what the backtraces of the other threads are..
would something like....
void TIME_MMTimeStart(void) { if(!InterlockedExchange(&TIME_activeTimer, TRUE)) { ...... } } }
void TIME_MMTimeStop(void) { if(InterlockedExchange(&TIME_activeTimer, FALSE)) { ...... } }
get around the critical section problems or should the code be change to use it's own critical section or both?
Cheers,
Jer
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com