Hi there,
I think you're doing some 'utopic struggling' here...
I've been using live555 within a multi-threaded context : it worked,
more or less, but I always saw my code as a dirty hack, and I was glad
to see the asynchronous API appear.
I'll be on Ross' side on this one, because I respect his choices (I
don't mean I agree with all of them though ;-) )
You can always make suggestions, but you shouldn't insist like that, I'm
afraid it's gonna rot into a sterile debate (or worse..)
By the way, nothing prevents you from implementing your own fork, with
thread support (that would be a big work...)
Best regards,
Guillaume.
Le 18/11/2010 00:18, Jeremy Noring a écrit :
On Wed, Nov 17, 2010 at 3:23 PM, Ross Finlayson <[email protected]
<mailto:[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
--
Guillaume FERRY
Bertin Technologies
Département Bertin Conseil
Activité Traitement de l'Information et du Contenu
/Tél/ 01.39.30.62.09
/Fax/ 01.39.30.62.45
/Mail/ [email protected]
/Web/ www.bertin.fr <http://www.bertin.fr>
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
