Deadlock with out-of-order calling of VideoSourcePlayer.WaitForStop and VideoSourcePlayer.SignalToStop.

[GoogleCodeExporter]

If, in a situation with multiple threads, one or more threads call WaitForStop 
before any thread calls SignalToStop, two things will happen:

First, the VideoSourcePlayer will stop updating upon the first call to 
WaitForStop, even though neither Stop nor RequestToStop has been called. Is 
this the desired behaviour for this situation?

Second, as soon any other thread calls Stop or RequestToStop on that 
VideoSourcePlayer, it will deadlock, as that thread can't acquire the lock on 
this until WaitForStop returns.

If the correct user behaviour is to only call methods on a VideoSourcePlayer 
from a single thread, then I'd drop the locks completely and enforce this by 
starting every method with
if ( !IsHandleCreated ) { CreateControl( ); CreateHandle( ); }
if ( InvokeRequired ) throw new Exception( );
(Obviously, a more specialized exception should be thrown.)

base.Size = base.Size or similar might also work, and, if so, would be more 
consistent with Control.CheckForIllegalCrossThreadCalls, but is likely to be 
removed later because it's logically a no-op.

Original issue reported on code.google.com by dales...@gmail.com on 20 Sep 2010 at 2:02

[GoogleCodeExporter]

Original comment by andrew.k...@gmail.com on 20 Sep 2010 at 1:39

• Changed state: Accepted
• Added labels: Milestone-Coming, Priority-High, Project-Video, Type-Defect

[GoogleCodeExporter]

Added check for cross-thread access to most methods/properties (those which are 
not allowed to be accessed from another thread). Lock is still kept in some 
methods/properties, which access video frame (this must be protected anyway).

Committed in revision 1348. Will be released in version 2.1.5.

Original comment by andrew.k...@gmail.com on 18 Nov 2010 at 4:05

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by andrew.k...@gmail.com on 12 Jan 2011 at 11:42

• Changed state: Released
• Removed labels: Milestone-Coming