I'm starting a project in which I'd hoped to use Boost.Signals but I see that it is not thread-safe. Is there a timeline for making it thread-safe? Thanks. -Dave
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:679138DE-524A-45E1-BB85-F3BE07BC2115@cs.indiana.edu...
On Dec 26, 2005, at 2:48 PM, David A. Greene wrote:
I'm starting a project in which I'd hoped to use Boost.Signals but I see that it is not thread-safe. Is there a timeline for making it thread-safe?
Unfortunately, no.
Any progress on a BOOST.Signals proposal for TR2? --Beman
Douglas Gregor wrote:
On Dec 26, 2005, at 2:48 PM, David A. Greene wrote:
I'm starting a project in which I'd hoped to use Boost.Signals but I see that it is not thread-safe. Is there a timeline for making it thread-safe?
Unfortunately, no.
Is there a desire to make it thread-safe at some point, or is it not seen as worthwhile? What would be involved in making it thread-safe? Additional runtime overhead? Additional library code? Both? Something else? -Dave
On Dec 29, 2005, at 3:25 PM, David A. Greene wrote:
Is there a desire to make it thread-safe at some point, or is it not seen as worthwhile?
Users have been asking for thread safety for years. It is *definitely* worth while, and has kept people from using Signals far too often.
What would be involved in making it thread-safe? Additional runtime overhead? Additional library code? Both? Something else?
There would be some run-time overhead, although it could be factored out into a threading policy if it was problematic. Dealing with deletion of trackable objects and disconnection of slots in a multi-threaded environment becomes rather tricky, both to implement and to specify. That, compounded with that lack of time I keep whining about, has conspired to keep Signals single-threaded even though we should have implemented multi-threaded support a long time ago. Doug
participants (4)
-
Beman Dawes -
David A. Greene -
Doug Gregor -
Douglas Gregor