more mmtimer questions

[Jeremy White]

Oliver Stieber wrote:
> I've had a look through the code and can't spot any
> problems with managing the linked list which would
> point to problems with TIME_TimersList but when the
> crash occurs ptimer != &TIME_TimersList

I looked as well, and couldn't see anything obvious.

The only 'flaw' I saw was that we used the WINMM_IData->cs,
when, for logical separation, it seems we should have
our own cs.  But I can't imagine any way in which
that flaw would create the condition you describe.

Some sub process causing heap corruption would
explain this.

> 
> 
> Also if the we're using a = &TIME_TimersList,
> a=&(*a)->lpNext  and then referencing *a in critical
> sections doesn't anything that modifies
> TIME_TimersList or ... lpNext also have to be in a
> critical section? e.g. TIME_MMTimeStart and
> TIME_MMTimeStop.
> 
> If so should the code be change to copy the values 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.

For correctness, I agree that the clearing of TIME_TimersList should better be
protected by a crit section; I admire your thoroughness on that.
I also don't understand why time.c shouldn't have it's own crit sec for the TimersList.

But a case where that could credibly become an issue is hard to imagine.  You
have to have 1 thread termintating the MM Timer while another thread
is simultaneously killing or setting an event.  Further, the event loops
inside the set and term event loops are pretty tight; 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.

Cheers,

Jer