-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 February 2007 18:19 pm, Timmo Stange wrote:

Gottlob Frege wrote:

...

What if I want to use a single-threaded signal in a multi-threaded program? ie some of my signals are multi-threaded, but I also have some signals (for UI updates?) that will only ever be on the main/UI thread.

Yes, same here. I also would like to set deferred notification (through a message queue) on top of signals where that is advised for performance reasons. There are several scenarios in which you can ensure the thread- safety externally and use a single-threaded signal.

I guess if that's what the people want. Allthough, I note that more ubiquitous and lower-level libraries like smart_ptr have gotten away with not providing a thread-safety template parameter. In any case, a problem I'd like to address is how painful it currently is to declare a thread-safe signal, the threading model being at the end of a long list of template parameters. Two possibilities come to mind. One is making lightweight_mutex the default ThreadingModel, maybe called "auto_threaded" and still providing single_threaded and multi_threaded for those determined enough to plow through all the template parameters. The other is providing a templated typedef class that uses a tweaked set of defaults for the template parameters appropriate for thread-safety. For example, mt_signal<Signature>::type might be a signal type using last_value for the combiner and signals::multi_threaded for the ThreadingModel. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF5uVK5vihyNWuA4URAvgoAKCFAMiIFK4cVQzmPeVU2G0qxBPG4QCgpKve MXGqKbGtQ8AQ69iTC7F5he4= =kHph -----END PGP SIGNATURE-----

Frank Mori Hess wrote:

I guess if that's what the people want. Allthough, I note that more ubiquitous and lower-level libraries like smart_ptr have gotten away with not providing a thread-safety template parameter. In any case, a problem I'd like to address is how painful it currently is to declare a thread-safe signal, the threading model being at the end of a long list of template parameters. Two possibilities come to mind. One is making lightweight_mutex the default ThreadingModel, maybe called "auto_threaded" and still providing single_threaded and multi_threaded for those determined enough to plow through all the template parameters. The other is providing a templated typedef class that uses a tweaked set of defaults for the template parameters appropriate for thread-safety. For example,

mt_signal<Signature>::type

might be a signal type using last_value for the combiner and signals::multi_threaded for the ThreadingModel.

There's a third alternative: I've added support for a generalized default parameter signals::use_default in my implementation, which allows specifying the ThreadingModel argument without providing an explicit SlotFunction argument. On a side note: Boost.Iterator uses "use_default" at the boost namespace scope and I wonder if it wouldn't be good to move such common phrases into a distinct part/library in a namespace with a short name. I'm using that in a class library of my own and call those words and phrases "tactics". They are only simple types and can be used for policy template parameters. So that "exclusive" can be used to instantiate a mutex template as well as a file template, for example - instead of exclusive_mutex and exclusive_file. Back to Signals: It's quite likely that a user will typedef the signals anyway, so a long instantiation name is not a big problem. Other cases where I'm reluctant to add too many parameters are situations in which that complicates the interaction between re- sulting types. That often speaks against an Allocator template parameter, but is not applicable here, either. You can still connect any type of slot to any type of signal - as long as the signature matches. Regards Timmo Stange