I had a threading issue with some libjingle code. Specifically, a race condition between a sigslot callback [OnStreamEvent()] and a disconnect () call [m_stream->SignalEvent.disconnect()]. Standard race condition issue where the target of the callback (the object with the OnStreamEvent method) was deleted but the worker thread still tried to invoke the callback. I solved it, (I'm pretty sure) by changing sigslot.h to build as multi_threaded_local, as opposed to the default single_threaded build.
I'm not posting to ask for help debugging my code. I just wanted to understand the rationale behind the decision to use sigslots in single_threaded mode within libjingle. I vaguely remember some documentation talking about this, but couldn't find it when I went searching again. I would think that since libjingle makes strong use of multiple threads, that the multi-threaded version of sigslot would be a natural fit. Other than performance, is there any downside to compiling sigslot as multi_threaded_local? I have other potential solutions to my bug but felt that using sigslot in multi-threaded mode was the most appropriate given the circumstances. Any help is greatly appreciated. Thanks. libjingle version: libjingle-0.4.0 platform: Windows XP, Visual C++ 2008 Express --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-talk-open" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-talk-open?hl=en -~----------~----~----~----~------~----~------~--~---
