[Live-devel] doEventLoop - problems stopping (and possiblystarting)

[Frances Flood]

Ross,

Thanks for replying. Additional below 


>>The first problem I'm having is that the event loop does not always 
>>stop when I set the flag.

>You must not be using it correctly.  Make sure that the "watchVariable"
is a single 8-bit 
>variable, which is visible both to the call to "doEventLoop()", and in
the place where it's 
>value is set non-zero.

>Note the implementation of "BasicTaskScheduler0::doEventLoop()" in 
>"BasicUsageEnvironment/BasicTaskScheduler0.cpp".

I'm using a char variable, as per liveMedia/SIPClient.{h,cpp} and
liveMedia/MPEG4VideoFileServerMediaSubsession.{h,cpp}. The variable is
visible both where doEventLoop is called and where it's set non-zero.

>>Investigations so far suggest the problem is that when 
>>BasicUDPSource::incomingPacketHandler1 is called, 
>>isCurrentlyAwaitingData is returning false, although 
>>FramedSource::getNextFrame sets the var (fIsCurrentlyAwaitingData) 
>>to true just before the event loop starts and I can't see any sign 
>>of the var being set to false.

>It gets set to False in several places in "liveMedia/FramedSource.cpp".

True. I didn't express myself very well. What I meant was that I wasn't
seeing the execution passing through the sections of code that would set
the var to false after the var had been set to true. However, this seems
to have been a red herring. I have increased the debug lines I've added
to help me follow the flow through the code, and the problem seems
slightly different, though no less confusing.

I start the sink playing, giving the following debug lines showing the
flow:

MediaSink::startPlaying
BasicUDPSink::continuePlaying1
FramedSource::getNextFrame                         awaiting data,
calling doGetNextFrame
BasicUDPSource::doGetNextFrame                     27914360 - socket
1468
BasicTaskScheduler::turnOnBackgroundReadHandling   FD_SET added socket
1468 to fReadSet  

Execution continues without any further FD_ZERO, FD_SET, FD_ISSET or
FD_CLR calls on fReadSet. It then enters BasicTaskScheduler::SingleStep
where the following happens (comment lines from the code given around
the debug lines):

//Call the handler function for one readable socket:
iterating through handlers 11189576
// To ensure forward progress through the handlers, begin past the last
// socket number that we handled:
lastSocket before - 1648, 
-- while within if statement
  HandlerIterator returning descriptor for 27920400, socket - 1468,
clientData - 27914360
  HandlerIterator returning descriptor for 27913088, socket - 1460,
clientData - 27915368
  HandlerIterator returning descriptor for 21683104, socket - 1572,
clientData - 21687688
  HandlerIterator returning descriptor for 21682736, socket - 1580,
clientData - 21686872
  HandlerIterator returning descriptor for 21682368, socket - 1640,
clientData - 21681744
  HandlerIterator returning descriptor for 25482384, socket - 1648,
clientData - 11181944
lastSocket after - 1648

-- second while loop
-- if statement
// We didn't call a handler, but we didn't get to check all of them,
// so try again from the beginning:
Checking again from the beginning - last socket = 1648
  HandlerIterator returning descriptor for 27920400, socket - 1468,
clientData - 27914360
  checking 1468
  HandlerIterator returning descriptor for 27913088, socket - 1460,
clientData - 27915368
  checking 1460
  HandlerIterator returning descriptor for 21683104, socket - 1572,
clientData - 21687688
  checking 1572
-- if statement
    // Note: we set "fLastHandledSocketNum" before calling the handler,
    // in case the handler calls "doEventLoop()" reentrantly.
    Calling handler - new last socket 1572

BasicUDPSource::incomingPacketHandler1 21687688
incomingPacketHandler1 - not awaiting data

So, "FD_ISSET(handler->socketNum, &readSet) &&
FD_ISSET(handler->socketNum, &fReadSet)" is failing (I have checked that
the handlerProc is not NULL) for 1468, though I can't find any reason
for it. I hope my explanation is clear? Any suggestions greatfully
received - I'm pretty stumped here.

Thanks,
Frances