[Libsigcx-main] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 2004.05.30 19:42 schrieb(en) Christer Palm:
> Hi Martin!
>=20
> Martin Schulze wrote:
>>=20
>> Which classes from libSigCX do you need? At some time I had some
>> random thoughts about libSigCX & sigc++-2.0 - Some things should be
>> much easier to implement with the new API.
>>
>=20
> My app depends rather heavily on SigCX::GtkDispatcher and SigCX::=20
> ThreadTunnel to do cross-thread signalling. I also pass around a lot =20
> of signal arguments by reference, so I also depend on beeing able to =20
> have fully synchronous signals.

I've just updated a dispatcher class I've been using for libsigc++ 2.0.
It's based on sigcx but only implements a subset of the functionality.
Maybe it can serve as a starting point for the port or you can just use =20
it. I can't test it myself because I still haven't updated to gtkmm-2.4
(low bandwidth connection :( ). Attached is a tarball that also
includes a simple (single-threaded) test program to illustrate the
usage:

  void foo(std::string text) {
    std::cout << text.c_str() << std::endl;
  }

  int main(int argc, char *argv[]) {
    Glib::thread_init();
    Gtk::Main myApp(argc, argv);

    sigc::GtkmmDispatcher disp;

    disp.tunnel(sigc::bind(&foo, std::string("hello world")));
      /*
         - call this function from any thread;
         - bind up to 7 arguments at once
         - pass 'true' as a second argument if the slot should
           be executed synchronously;
         - make use of signal::make_slot() if the dispatcher
           should emit a signal;
       */
  }

The dispatcher tunnels slots across threads. It uses a Glib::Dispatcher
internally to trigger their execution. For performance reasons an extra =20
list class is included to store the slots: 'ringbuffer' - a fixed-size =20
list that supports multithreaded addition/removal of objects without =20
any locks. (It can be replaced by a std::list and a mutex easily.)

To pass return values across threads an additional adaptor class would
be needed.

Regards,

  Martin


> Perhaps it would be a good idea to extend the existing Glib::=20
> Dispatcher mechanism to provide the functionality of SigCX? IMO, =20
> Glib::Dispatcher is rather useless in its current form, and yet, =20
> cross-thread signalling is definitely one of the, if not _the_, most =20
> convenient and elegant way of doing multithreaded gtkmm =20
> programming...
>=20
> --
> Christer Palm