RE: [GD-Windows] Stopping a thread cleanly

[Brian H. <bri...@py...>]

> I don't see why a critical section would be necessary in that loop. 

It's a guard around the shared data accessed in DoWork().

> There's no shared state going on between the player and the killer, 
> except for the event, which is protected enough without the critical 
> section.

Actually, there is shared state -- in this case, they're both trying to
dork with an LPDIRECTSOUNDBUFFER.  The killer immediately releases it
when the thread is done.  I could have the thread do this, but sometimes
I just want to stop the thread without releasing the buffer.
 
> Anyway, the problem with this is that you delay shut-down (while 
> spinning, waiting for that global) for whatever your sleep time is. 

Which is why I'm WFSO now instead of just a pure sleep.

> DirectSound supports playback notifier events, so you can set an 
> event, say, every 100 milliseconds played, and use this event to 
> wake up and fill the buffer.

Except those don't work all the time.  Way back when, Candy Cruncher
used notifications, until I started getting E_NOINTERFACE failures on
some older drivers and sound cards.  Getting rid of those made my audio
a lot more robust.

> Regarding declaring members or globals "volatile" when they're shared 
> between threads: that's what the keyword is for, so I don't see how 
> that is considered ugly (assuming you need that semantic)?

I was originally going to declare the _class_ as volatile, which
suddenly breaks a lot of things (respecing volatile is much like
respecing const -- it ain't plug and play).  But just specing that one
member would have worked (and is all that's necessary).

Brian