Open vadi2 opened 10 years ago
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.
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.
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 :-)
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.