That doesn't matter, because *TCP* packets will still be arriving
(on the TCP socket), and will be handled. This is a Red Herring.
No, that TCP socket has been closed - and the corresponding socket
ID refers occasionally to an UDP socket within the same call to
SingleStep - if it was a red herring the TaskScheduler was not going
to be stuck. That's a fact, not an argument. I have debugged a real
problem, not imagined one.
I have no doubt that your problem is real. However, your proposed
solution - messing with the "BasicTaskScheduler" code - appears to be
merely masking your real problem: That incorrect socket numbers are
getting passed to the call to "select()" in the event loop.
You should make sure that
"TaskScheduler::turnOffBackgroundReadHandling()" gets called on each
socket once it's no longer being used (before its number gets
reclaimed for another socket). There's apparently something about
your custom code that is causing that not to happen for some sockets.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
