One last question on this, as I'm in the middle of reorganizing the code.

Shouldn't it be safe to create the rtspClient object in another thread?

 

Once again, NO!  "RTSPClient" objects - like all subclasses of class
"Medium" - update shared data structures (stored within the
"UsageEnvironment" object) when they are constructed.  A single
"UsageEnvironment" object MUST NOT be accessed from multiple threads (except
that the "triggerEvent()" member function may be called from a
non-LIVE555-event-loop thread).

 

 

 

Got it. I'm happy that I asked...

 

For a class that's created outside of liveMedia, it still seem safe to store
temporary variables even though they can be accessed via the rtspClient
object. I'm thinking of StreamClientState (as used in the testRTSPClient
example). It is only part of OurRTSPClient, not RTSPClient. If I add a
variable there that I know is only accessed in two places, it appears
perfectly safe even if it will be written to from one thread and read from
another.

 

 

I can't think of any problems passing arguments that way. If anyone see any
possible issue, please enlighten me what could potentially go wrong.

 

In the example below, SeekAbsolute() will execute on a second thread,
assigning scs.seekToAbsolutePosition, while SeekAbsoluteEvent() will be
executed on the liveMedia thread reading the value.

 

void SeekAbsolute(OurRTSPClient *rtspClient, char *seekTo)

{

     if (rtspClient)

     {

           // Pass on the argument.

           StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs;

           strcpy_s(scs.seekToAbsolutePosition,
sizeof(scs.seekToAbsolutePosition), seekTo);

 

           UsageEnvironment& env = rtspClient->envir();

           env.taskScheduler().triggerEvent(mySeekAbsoluteEvent,
rtspClient);

     }

}

 

 

void SeekAbsoluteEvent(OurRTSPClient *rtspClient)

{

     StreamClientState& scs = ((OurRTSPClient*)rtspClient)->scs;

     rtspClient->sendPlayCommand(*scs.session, continueAfterPLAY,
*scs.seekToAbsolutePosition);

}

 

 

/Claes

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to