[signals] thread-safe combiner()
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In implementing some of the missing parts of thread_safe_signals, I noticed that boost::signal provides a non-const combiner() function. In it's current form, it can't be made thread-safe against signal invocation. Is it worth changing the prototype from combiner_type& combiner(); to void set_combiner(const combiner_type &); so the combiner can only be modified while holding the appropriate lock? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFy55q5vihyNWuA4URAiHbAJ45kSHJDeBOCKy+s5Yc6TwzqoclkACgx7PY vLAMNIfrlNQWu1jXFppxOj4= =9yLn -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
combiner_type& combiner();
to
void set_combiner(const combiner_type &);
so the combiner can only be modified while holding the appropriate lock?
If you want to keep the interface somewhat more compatible, you could return a proxy which acquires the lock in its assignment operator. Making the other possible uses thread- safe is more complicated (signal.combiner().member()). Regards Timmo Stange
On Feb 9, 2007, at 4:16 AM, Timmo Stange wrote:
Frank Mori Hess wrote:
combiner_type& combiner();
to
void set_combiner(const combiner_type &);
so the combiner can only be modified while holding the appropriate lock?
If you want to keep the interface somewhat more compatible, you could return a proxy which acquires the lock in its assignment operator. Making the other possible uses thread- safe is more complicated (signal.combiner().member()).
My impression is that very few users actually need to modify the combiner in this way. I think we should stick with the "right" interface, which probably meets having "combiner" return by-value and adding "set_combiner". Cheers, Doug
participants (4)
-
Douglas Gregor -
Frank Mori Hess -
Timmo Stange