<div>sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do</div>
<div>moreover you're doing several unrelated changes in the same patch, please split up</div>
<div><br>A+<br><br></div>
<div class="gmail_quote">2011/3/28 <span dir="ltr"><<a href="mailto:Joerg-Cyril.Hoehle@t-systems.com">Joerg-Cyril.Hoehle@t-systems.com</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi,<br><br>- PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs<br>�anymore, which makes it easier to reason about use of critical sections.<br>
- psStopEvent was never used like an event rather than a boolean.<br>- No need to muck with WHDR_DONE.<br>- No need to keep the unused thread handle object around.<br>- Abort the playloop in case of error, like I did for mciwave. �The error<br>
�may not be transient.<br><br>- Free waveHdr and hEvent after closing hWave. �Either you believe that<br>�WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must<br>�not yet be freed, or you believe checking for STILLPLAYING is a waste of<br>
�code because waveOutReset must have done its job.<br><br>�I should have added an ERR() message.<br><br>�One should think again about what to do in such a case. �Why/when would<br>�sleep help? �User-friendlier might be not to wait, not to free WaveHdr<br>
�and accept to leak resources in such a case.<br><br>�Actually, waveOutClose can fail with STILLPLAYING because waveOutReset<br>�can fail. �If you look at winealsa, you'll see it uses CreateEvent to<br>�synchronously wait for acknowledge of the message. �Now guess what<br>
�happens if CreateEvent fails because memory is tight?<br>�What happens in the app when waveOutClose's CreateEvent fails?<br>�It's always tough to reason about the many error paths.<br><br>Regards,<br>� � � �J�rg H�hle<br>
<br><br><br></blockquote></div><br><br clear="all"><br>-- <br>-- <br>Eric Pouech<br>