On Fri, Aug 26, 2016 at 08:48:23AM -0600, Ross Finlayson wrote: > > 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).
The sole purpose of those changes is to separate those afterGetting calls into ones that do set fNextTask to NULL and those that don't. I do agree though that applying it as is may be harmful, because it breaks API, because the API is broken and it is impossible to correctly use it. I also agree that replacing the fNextTask mechanism would be even better. It appears that your 2016.08.27 release did pull the bulk of the other changes of my patch. Thank you. > 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. Let me propose a good reaons to use a TaskScheduler from multiple threads: Consider an application that separates stream capture and stream delivery (using liveMedia) into different threads. Then captured frames need to be communicated to liveMedia for transmission. It seems that a good way to do so is creating a trigger and then passing frames via TaskScheduler::triggerEvent from the capturing thread. Thus the only method that non-liveMedia threads invoke is TaskScheduler::triggerEvent and this seems to already be endorsed by the FAQ, no? Quoting the FAQ: | Note that "triggerEvent()" is the only LIVE555 function that may be | called from an external (i.e., non-LIVE555) thread. The reason that I am using my own TaskScheduler instead of BasicTaskScheduler is that BasicTaskScheduler::triggerEvent is not thread-safe. Using different TaskScheduler objects is not possible, because the purpose of sharing the same object is to mediate communication (via triggerEvent). Using different objects would mean never delivering any frames. Helmut _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
