That's fine with me. trunk/HEAD is already for a future glibmm 2.13, so it can be checked into there.
Would this deprecate the existing Dispatcher? I guess that it should. On Fri, 2007-01-19 at 08:44 +0100, Daniel Elstner wrote: > Hello everyone, > > I recently learned that the POSIX memory visibility rules aren't as > strict as I thought them to be (thanks to Chris for pointing this out). > Given this, I'm now considering an API addition to glibmm, namely a > Glib::Dispatcher1<T> template that allows passing an argument to the > receiving end. What I have in mind is this: > > 1) The Dispatcher1<T> template would be restricted to > fundamental types. Note that this includes pointers to > arbitrary types. > > 2) The data argument is packed into a union and sent over the > pipe as is. As with the old Dispatcher, the pipe will be shared > among all Dispatcher and Dispatcher1<T> instances created by the > receiver thread. The plain old Dispatcher will just send a > dummy argument across the pipe. > > 3) There will be the following specializations: > Dispatcher1<T*> > Dispatcher1<const T*> > Dispatcher1<float> > Dispatcher1<double> > > 4) The non-specialized Dispatcher1<T> template will treat T as > an integer type, convertible without loss to unsigned long long > and back. Unless T provides implicit conversions to integer > type, this will fail to compile with custom types. That way, > the restriction to fundamental types is enforced. > > 5) The constructor of the underlying, non-templated > DispatcherImpl (or whatever) class will take a boolean > is_dynamic argument. If this is set to true, the implementation > will lock around reads to and writes from the pipe. Only the > Dispatcher1<> specializations for pointers will expose this > parameter in the public interface, with a default value of true. > For any other T, is_dynamic will always be false. > > This is a pretty conservative approach. The API will make sure that > you'll have to try hard to break memory visibility rules. It will be > just as fast as the old Dispatcher, except for pointer types where > is_dynamic is true by default. And even that can be overridden if you > know what you're doing. > > The new class needs to have a different name in order to maintain API > and ABI stability. The name Dispatcher1<T> would match the old > sigc::signal1<> convention, where the 1 indicates the number of > arguments. Maybe you can think of something better. (Though I really > don't want to call it DispatcherWithData or something.) > > Now the coolest thing is: This is actually quite easy to implement, as > all the hairy code is already in place. Shouldn't take more than a > couple of hours, really. > > What do you think? Am I completely on crack? Any suggestions? > > Cheers, > --Daniel > > > _______________________________________________ > gtkmm-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
