When scheduling a delayed task, one receives a TaskToken. This token can
be used lateron for cancelling the task. Or the task could be run in the
interim and the token could be reissued for a different task. If the
task is unscheduled at this point, this consitutues a use-after-free
scenario. Accor
On Mon, Sep 12, 2016 at 06:55:53AM -0700, Ross Finlayson wrote:
> This is the *first* thing that you should have told us. This told me all
> that I needed to know: That there was a bug in
> “GenericMediaServer::createNewClientSessionWithId(). It should have checked
> that the “createNewClientS
On Mon, Sep 12, 2016 at 02:02:33PM +0200, Ross Finlayson wrote:
> Rather than making an obscure reference to a 6-year-old message (that was
> likely in response to something completely different to what you’re concerned
> about), why don’t you just ask the question you really want to ask? That
On Wed, Sep 07, 2016 at 10:12:58AM -0700, Ross Finlayson wrote:
> It depends. Most of the “createNew()” functions just do
> return new SomeConstructor();
> Should that fail, then things are TARFU anyway (see
> https://en.wikipedia.org/wiki/List_of_military_slang_terms#TARFU :-)
In this con
Hi,
I was wondering whether createNewSomething methods may return NULL. The
library itself appears to be inconsistent here as a quick survey of
random functions turned out:
Some invocations are not checked for whether a createNew returns NULL.
* OnDemandServerMediaSubsession:getStreamParameters d
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
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
>
On Tue, Aug 23, 2016 at 05:14:04PM +0200, Ross Finlayson wrote:
> Furthermore, once a ‘scheduled task’ has occurred, its ‘TaskToken’ is no
> longer valid, and should not be used again. Therefore, you MUST NOT call
> “unscheduleDelayedTask()” (or “rescheduleDelayedTask()”) on a ‘TaskToken’
> aft
Thank you for the quick reply.
On Tue, Aug 23, 2016 at 05:14:04PM +0200, Ross Finlayson wrote:
> I’m not sure I understand the motivation for your question, because
> “unscheduleDelayedTask()” is a function that should be called only rarely.
> Note that once a ‘schedule task’ has occurred (once
Hi,
I'm wondering about the correct way to use
TaskScheduler::unscheduleDelayedTask. I see a few options, but none seem
to be consistent with the live555 code base or sane.
Option 1
scheduleDelayedTask never returns the same token. A user can call
unscheduleDelayedTask before or after th
10 matches
Mail list logo