[Live-devel] correct way to use TaskScheduler::unscheduleDelayedTask?

[Helmut Grohne]

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