Robert Reif a écrit :
Reduce the use of the dsound global variable by passing address to functions. This is in preparation of supporting multiple DirectSound devices. We can't remove all uses because an mmtimer callback can be called even after the timer is killed. Windows has an mmtimer flag that prevents this but wine doesn't implement it.
Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).
Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).
I mean the _timer_ is killed...
Eric Pouech a écrit :
Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).
I mean the _timer_ is killed...
and please forget my first post (I didn't look at my own comments in the file :-( You're right, timeKillEvent isn't synchronous :-( A+
I looked at extending the lock to cover the callback when it was 32 bit code and The TIME_KILL_SYNCHRNOUS flag was set but I was concerned about the performance hit and didn't pursue it further.
Eric Pouech wrote:
Robert Reif a écrit :
Reduce the use of the dsound global variable by passing address to functions. This is in preparation of supporting multiple DirectSound devices. We can't remove all uses because an mmtimer callback can be called even after the timer is killed. Windows has an mmtimer flag that prevents this but wine doesn't implement it.
Could you be more specific on this one ? timeKillEvent is not 100% thread safe (I'll send a patch later on), but timeKillEvent in Wine is always synchronous (ie the killer is killed when timeKillEvent returns).
-
Eric Pouech -
Robert Reif