> On Fri, Aug 26, 2016 at 12:07:45PM +0200, Ross Finlayson wrote: >> Yes, you are correct here. Fortunately, there is an easy fix (which I’ll >> add to the code in the near future): Set “fNext” to NULL at the start of the >> handler function (“sendNext()”). Ditto for the other places in the code >> where the same thing is done. > > That's exactly what my patch does.
No, it’s not. Your patch does a whole lot more (all of the “afterGetting()” changes). There’s no way I’m going to apply such a large patch to the code base (especially because, as I noted before, the proper long term solution (replacing the “fNextTask” mechanism entirely) will be a non-trivial change as well). >> You absolutely MUST NOT try to access a “TaskScheduler” (or any other >> LIVE555 object) from more than one thread. As explained in the FAQ, the >> LIVE555 code was designed to be run as a single-threaded event loop. (It >> *is* possible, however, to run LIVE555 code from more than one thread, if >> each thread uses its own “UsageEnvironment” and “TaskScheduler” object - >> again, as explained in the FAQ.) > > Well, that FAQ entry is slightly wrong here. It really should say > BasicTaskScheduler instead of TaskScheduler. If a downstream of > liveMedia implements a subclass of TaskScheduler in a thread-safe way > (and that includes never accessing other live555 objects from other > threads), then accessing such a TaskScheduler subclass from another > thread is indeed safe. Well, maybe - but I don’t see the point of having two or more threads share a single (special, thread-safe) “TaskScheduler” (subclass) object, while (somehow) making sure that the threads don't share access to any other LIVE555 object. Why not just have the threads use different “TaskScheduler” (and “UsageEnvironment”) objects - something that’s much safer? But anyway, if you want to go the route of writing and using your own single (special, thread-safe) “TaskScheduler” (subclass) object, you’re on your own. That’s not something that I’m going to endorse. 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
