On Wed, Nov 17, 2010 at 3:23 PM, Ross Finlayson <[email protected]>wrote:
> > Well, I have to admire your stubbornness :-) Even after having presented > a perfect example of why that statement is false, you continue to insist > otherwise. > I take it back, I will belabor the point. Yes, this is "stubbornness," and no, you did not present a "perfect example of why that statement [was] false." The bottom line is yes, you can run Live555 in a threaded environment (I've been doing it for over a year now) so long as you have a dedicated thread for the event loop (your own FAQ states this). And there are plenty more ways of communicating changes to the event loop besides global variables (in fact, doing so is just sloppy-bad code, in my opinion; I struggled with some of Live555's crappy global variables that made running multiple independent instances with dedicated threads run in the same process space). Furthermore, there is _nothing_ wrong with setting a read-only boolean variable that the event loop then subsequently checks. There is almost zero functional difference between this and your global variable option. There's nothing stopping someone from doing it that way with the change I proposed, and I think saving an additional NULL check in exchange for potential threading woes isn't worth it (if you're looking to optimize, I can point you towards about a dozen things in your library that dwarf such a check). So fine, attribute it to "stubbornness," but again, the patch I posted here has not only been tested but it _works_. It does this in a threaded environment, which your own library is completely compatibile with given a few pretty obvious caveats (first and foremost, a dedicated thread for the event loop).
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
