> On Aug 12, 2015, at 6:59 PM, Jeremiah Morrill <[email protected]> 
> wrote:
> 
> I’ve come across an issue where a BasicTaskScheduler0 gets statically 
> initialized (ran before main(…))

I don’t see how this can be happening with the code that we’ve supplied, 
because the “BasicTaskScheduler0” constructor is protected, and the only 
subclass of “BasicTaskScheduler0” that we define is “BasicTaskScheduler”, which 
also has a protected constructor (and whose objects are created only by a 
“createNew()” function).

But perhaps you’ve defined your own subclass of “BasicTaskScheduler0”, and are 
declaring an object of that subclass statically??  I’d advise against this, 
because the distinction between “BasicTaskScheduler0” and “BasicTaskScheduler” 
is historic and rather arbitrary - and in the future the “BasicTaskScheduler0” 
class might get folded back into “BasicTaskScheduler”.

In any case, as you’ve discovered, declaring these objects statically this is a 
bad idea (and was never intended).  So you shouldn’t do it :-)


> Essentially in a statically initialized environment, the ETERNITY const may 
> not have been set

There may be other uninitialized things as well that the “BasicTaskScheduler” 
depends on.  So once again, to be safe, you shouldn’t declare this statically.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to