On Wed, 21 Jun 2000, Ove Kaaven wrote:
> Haven't people paid attention to recent developments? Surely you can't
> have missed that I have been working on a DirectSound restructure... and a

Yea, but _so much_ was working better :)  (Caesar III didn't play sound at all
before you started fixing dsound)

> restructure often means changing fundamental things like threading too...
> or at least fixing existing bugs. With my new implementation some
> thread-unsafety bug became more obvious to me during "testing" today... I
> think I'll submit a patch after Alexandre commits my previous patch, but
> the fix is basically:
> 
> 1. Find DSOUND_MixPrimary
> 2. Remove the AddRef and Release calls in it.
> 
> Fix done. This does not harm, because the DSOUND_MixPrimary is protected
> by the dsound->lock, which the DirectSoundBuffer::Release needs to acquire
> before releasing itself anyway! It is exactly because the MixPrimary is
> protected by the dsound->lock, which DirectSoundBuffer::Release waits for
> *after* decreasing its own reference count to zero, that a problem occurs;
> the AddRef increases from 0 to 1, and the Release decreases it back to 0,
> and then deallocates the buffer. After the mixer thread finishes its job,
> dsound->lock is released, and then the *original* Release tries to
> deallocate the buffer... BOOM!

Will this work with 200005xx?
                        -fjr

-- 
Frank J. Ramsay
[EMAIL PROTECTED]

Reply via email to