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

[Christer P. <pa...@no...>]

A few comments in addition to what Martin already wrote...

Daniel Elstner wrote:
> 
> How does this synchronous thing work?  Does it really wait for the main
> loop to process the signal, and wouldn't that defeat the purpose of
> threads? 

It's just a convenient form of locking for those apps that wants/needs 
it. Usually, it is perfectly acceptable to block until the signal 
handler returns. It definitely doesn't defeat the purpose of threads.

> Even if it does this you still need mutex locking to protect
> the memory being shared (ensuring that event A happens after event B is
> not enough due to the way modern hardware works; you definitely need
> memory barriers too).
> 

Synchronous signals _does_ use a mutex behind the scenes to implement 
the locking. Not that, AFAIK, mutexes does anything more than ensuring 
that event A happens after event B.

> Also, you can always use plain Glib::Dispatcher in conjunction with a
> Glib::Mutex to pass data around.  This way you're forced to think about
> the locking which is IMHO a good thing.
> 

IMHO, this is like saying that function arguments are unnecessary, 
because you could always use global variables to pass data around.

> When I thought about adding signal parameter support to Glib::Dispatcher
> a while ago, I played with the idea of making Glib::Dispatcher provide a
> low-level interface for sending raw blocks of memory through the pipe.
> On top of that there could be some kind of plugin interface that
> requires you to implement two functions that convert your data to raw
> memory and back again.

Isn't this exactly what CORBA, for example, is all about?
While it



>  I don't think it should be entirely automagic
> through templates since that'd give the user a false sense of security.
> The big advantage of course is avoidance of any locking whatsoever.
> 
> Comments, corrections, insights, etc. will be appreciated.
> 
> Cheers,
> --Daniel
> 
> 
> _______________________________________________
> gtkmm-list mailing list
> gtk...@gn...
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>