Re: Glib::Dispatcher1<T>

[Murray Cumming <murrayc murrayc com>]

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
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com