On Wed, Nov 17, 2010 at 1:37 PM, Ross Finlayson <[email protected]>wrote:
> That would work. But it might also lead to crashing issues if people >> call setAuthenticationDatabase on something other than the primary Live555 >> thread. (I can envision a scenario where something calls >> setAuthenticationDatabase(NULL) at precisely the moment between the NULL >> check and the actual authentication with the UserAuthenticationDatabase*, >> which would result in dereferencing a null pointer). >> > > And that is *precisely* why you should not be doing this. I've made it > very clear (in the FAQ and elsewhere) that LIVE555 applications have a > single thread of execution (using an event loop, rather than threads, for > concurrency). Other threads should not access the library (except perhaps > to set global variables - e.g., 'watch variables' that the event loop may > use to detect 'events'). If you do otherwise, then you can't expect any > support. I disagree. There is nothing wrong with this method of using the library, and my change would functionally allow both. I know your position on threads (or the lack thereof) and I don't expect you to accept my patch, so I won't belabor the point.
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
