Glib::Dispatcher1<T>

[Daniel Elstner <daniel kitta googlemail com>]

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