I didn't know this class existed I swear :) .

Anyway, you're totally right, this unconditional unblocking in my example would definitely have led to problems.

Is there any specific reason why you store a pointer instead of a reference to the connection? Just curious...

Regards,

Markus

-----Ursprüngliche Nachricht-----
Von: Jon Cruz [mailto:jon@...18...]
Gesendet: Sonntag, 9. März 2014 21:47
An: Markus Engel; Martin Owens
Cc: Inkscape Developer Mailing List
Betreff: Re: [Inkscape-devel] Blocking Signals

On Mar 9, 2014, at 1:39 PM, Markus Engel wrote:

> Hi,

> if you want to use this, I'd suggest creating a class like this:

> class signal_blocker {

> public:

http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/util/signal-blocker.h

Good thinking. However there is another common problem. If you block a signal, then call another function or so that end up also blocking the signal, then the latter code will unblock the signal early.

The code recently added in signal-blocker.h addresses this by checking at construction time and only blocking if it is not already blocked. Then as it is destructed it only unblocks if the instance blocked to begin with.

However, we do need to take care on when and where we block, and to minimize issues. One approach is to block signals. Another is to not cause signals to be emitted in the first place. We've had need of both those plus a few more in fixing problems in our codebase.