A 'complete' unblock method?

[vadi2]

There seems to be a missing method to completely unblock a signal, or even to check how many times would you need to unblock a blocked signal.

In a design where you have several things unblocking a signal, and the signal then self-blocking from going off again, this presents a problem. It works fine in a 1:1 mapping, but not here.

[katcipis]

Actually i think the idea was that each one that blocks is responsible for unblocking it (like reference counting). Letting someone just unblock all is like allowing someone to destroy a object that has reference counting, other parts of the code still needs the object, but you forced its destruction.

Now imagine that 3 different components blocked a signal, and they each one is doing stuff they need to do before unblocking, they are relying on the fact that the signal has been blocked, and all of a sudden someone unblocks it, it will break the semantic of the code that blocked it, you loosed orthogonality.

But to be completely honest, i never used the blocking feature, i just followed gsignal features. It was not a good idea since it bloated the API with stuff that are still not necessary, since i do not have a case use for this, it is hard to think on the best way to model it.

If you have a case use, then it is best for us to discuss about it.

[vadi2]

I have signals that fire regularly that describe a particular event happening, and I have one particular listener who depends on that signal and another condition to go off. How I modelled is that I set the other condition to unblock the listener whenever needed - this then enables this double condition of a signal + regular event, and it goes off. It then self-blocks inside the call, waiting for the condition to hit again.

In my use case I needed to add another condition that would enable it - so the modelled pattern of it getting enabled now is (regular event and condition1) or condition 2. condition1 is modelled just as an unblock, so when the regular event goes around again, my function fires, and then it self-blocks condition1. condition2 is modelled just as an :emit(), because it is stand-alone. I quickly found out that condition1 self-blocking inside my function though, when it went off condition2, was causing problems with the reference counting.

It is due to the design of the block/unblock method, so I cannot complain much - but I'd like to find a way to deal with this limitation! Right now, I separated out the code that deals with condition2 and made its own signal for it.

[katcipis]

I have to admit that without more details about the problem it is quite hard to think on alternatives, usually the domain of the problem reveals the alternatives, i really didn't get the problem, sorry :-)