Re: [Boost-users] [signals] dropping ThreadingModel template parameter

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-01 09:38:01

-----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<optional<R> > 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-----