Re: glibmm thread safety [was: Re: Adding custom GDK events]

[Murray Cumming <murrayc murrayc com>]

On Mon, 2007-01-15 at 18:03 +0100, Daniel Elstner wrote:
> Am Montag, den 15.01.2007, 12:14 +0000 schrieb Chris Vine:
> 
> > > Doomed, I'd say.  At least the call to remove_destroy_notify_callback()
> > > after the GSource mutex has been unlocked is unavoidable with the
> > > current API.  Maybe we'll be able to play some tricks and put something
> > > entirely different into the sigc::connection object.  A special-purpose
> > > slot which holds a connection ID or something, and goes through the
> > > GMainLoop/GSource interface to destroy the callback slot.
> [snip]
> > Better still for this usage, perhaps there could be a 
> > SignalIdle::single_connect() method which returns nothing and which will 
> > disconnect the callback whatever it's return value once it has been executed 
> > (in other words, it expects a void return value from the callback).
> 
> I like that idea.  It's useful beyond solving the threading problems as
> well, as you no longer need to use sigc::bind_return(), or change the
> code to return a boolean.  I'd prefer to call it connect_oneshot() or
> connect_once(), though.  Murray?

Sounds generally fine, as long as there's clear documentation saying
when you should use it, and when not to use the other one.

And if the existing method should not be used then it should be
deprecated.

I'd like to see the bug in bugzilla before it goes into svn, please.

> In any case, the current plain connect() should of course be fixed too,
> if at all possible.  But that'll be more difficult than introducing the
> alternative API.

If that's actually possible, as an alternative to adding API, it sounds
nicer. 

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com