[haiku-development] Re: Signals and Slots
- From: Alex Wilson <yourpalal2@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 28 Feb 2012 15:12:26 -0700
On Tue, Feb 28, 2012 at 2:56 PM, Pete Goodeve <pete.goodeve@xxxxxxxxxxxx> wrote:
>
> [I've pulled this out of the R1/A4 thread because it's wandered pretty
> far OT, but I thought it worth one more note]
>
> It looks as if we could get pretty adequate "Signals and Slots" in Haiku
> with no changes to any kits and essentially no effort. I've been playing
> some more with sigslot.h ( http://sigslot.sourceforge.net/ ) and it's looking
> pretty capable. I suggest that anyone interested in the paradigm should
> check it out. We could even put it in the distribution, as it's nothing but
> a 5K public domain header!
>
> I thought initially that it might not be a solid implementation of the
> concept -- would it handle the deletion of an object with a connected
> slot, for instance? It turns out it does so nicely. I can create a window
> with a slot, for instance, connect to it, see the signals arriving, then
> Quit the window. The connection is cleanly broken, and the program
> goes happily on. Everything seems well protected with mutexes, so
> it should be solid.
>
> And there's no real downside to slots being executed in the calling thread.
> Just like I often do with a BWindow or other looper, you just put a Lock
> around any critical section.
>
> Alternatively, I could just use a BMessage as the signal data and connect it
> to a single slot in the looper that simply posts the message to itself.
> Then it's handled in MessageReceived as usual. It's not the Qt way
> of having a slot for each kind of signal, but "it's the Haiku Way"... (:-)
>
> You might think this is just a roundabout way of doing the usual
> PostMessage to a looper, but the big difference is that there is no
> fixed link between the signaller and the receiver (or receivers).
> You can set up the message and send it out without worrying
> exactly who is going to do anything with it. And connections are
> dynamic -- make or break them at any time.
>
> To reiterate, I don't see any need for signals and slots to replace
> BMessages for most uses, but I can envisage places where their
> dynamic, many-tomany, connections could be useful. I have at
> least one possible use in my own code.
Think of signals and slots as syntactic sugar. We can achieve the same
thing with BMessages/BHandler/BLooper, but it's more verbose. For
instance, what you're describing basically sounds like the
notices/watching mechanisms of BHandler [0]. With this API, another
BHandler can subscribe to events (signals) with a specific 'what'
coming from a specific handler. The events are sent as a message with
the 'what' of B_OBSERVER_NOTICE_CHANGE the original 'what' is
available in the message as well. The developer doesn't have to keep
track of who's listening to which signals, and stale listeners are
even discarded automatically. Because it uses BMessengers and
BHandlers, this works cross-thread or even cross-process.
Anyway, sigslot does sound pretty nice, and it's nice to know at least
that we have the option of a standard-based signals and slots
implementation (even if we reimplement it ourselves for better
threadiness).
--Alex
[0]http://www.haiku-os.org/legacy-docs/bebook/BHandler.html#BHandler_SendNotices
Other related posts:
