Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A more general signal/slot implementation

Hi all,

the signal/slot mechanism in Qt is a powerful method for event/message exchange between instances of QObject.
It is used in various places in WebCore. However the WebCore implementation uses direct references to WebCore classes involved in the signaling process. This makes it difficult to use signaling for other purposes.

QObject instances embed a KWQSignal for each signal it may emit. Each KWQSignal is initialized by the object constructor with its name and an empty list of slots. When a slot is connected, a KWQSlot object representing both the target object and the slot method is inserted in the list.
A signal is then emitted with its arguments by calling the KWQSignal overloaded call method. The KWQSignal iterates through the list of KWQSlot and call the overloaded <x-tad-bigger>call</x-tad-bigger> method with the same arguments it has received. Each KWQSlot in turn call the proper slot method to the target object based on a slot method index.

<x-tad-bigger>Sender KWQSignal KWQSlot Target 1
| | | |
->|signal(arg1Type arg1, arg2Type arg2...) | |
| | | |
| | | |
| | | |
|-------------->|call(arg1Type arg1, arg2Type arg2...) |
| | | |
| | | |
| |(for each KWQSlot) | |
| |--------------------------->|call(arg1Type arg1, arg2Type arg2...)
| | | |
| | |(depending on |
| | | m_function) |
| | |---------------------->|slot(arg1Type arg1, arg2Type arg2...)
| | | |
</x-tad-bigger>

This implies that both KWQSignal and KWQSlot classes know in advance what set of parameters are used in signal emission. Furthermore the call methods in KWQSlot must know explicitly which slot methods can be called on target objects and to what classes belong the target objects.
In order to extend signaling to other QObject subclasses and slot methods, it is necessary to modify both KWQSignal and KWQSlot and make them aware of the classes and methods involved.

In order to get rid of this limitation:
- the KWQSlot class should not rely on a predefined set of slot methods. We can obtain this with pointers to member functions. A possible implementation would be to ask the target object himself for a function pointer when a slot is connected to a KWQSignal.
- the KWQSignal class should not rely on a predefined parameter lists. A unique (not overloaded) method should be called whatever the parameters of the signal/slot methods, it is then up to this method to duplicate the actual parameters during calls to the slot methods.

My suggestion is:
1- add a method to QObject that would return the address of slot methods from their names. Either a virtual method with predefined name->pointer mappings or a non virtual method that would look into a slot dictionary initialized at construction time. For instance:
<x-tad-bigger> void *KSVG::SVGDocumentImpl::slotFunctionPtr(const char *slotName) const {
if (KWQNamesMatch(slotName, SLOT(slotPaint())))
return (void*)&SVGDocumentImpl::slotPaint;
if (KWQNamesMatch(slotName, SLOT(executeScripts())))
return (void*)&SVGDocumentImpl::executeScripts;
if (KWQNamesMatch(slotName, SLOT(slotSVGContent(QIODevice *))))
return (void*)&SVGDocumentImpl::slotSVGContent;
if (KWQNamesMatch(slotName, SLOT(slotFinishedParsing(bool, const QString &))))
return (void*)&SVGDocumentImpl::slotFinishedParsing;

if (KWQNamesMatch(slotName, SIGNAL(gotDescription(const QString &))))
return (void*)&SVGDocumentImpl::gotDescription;
if (KWQNamesMatch(slotName, SIGNAL(gotTitle(const QString &))))
return (void*)&SVGDocumentImpl::gotTitle;
if (KWQNamesMatch(slotName, SIGNAL(gotURL(const QString &))))
return (void*)&SVGDocumentImpl::gotURL;
if (KWQNamesMatch(slotName, SIGNAL(finishedRendering())))
return (void*)&SVGDocumentImpl::finishedRendering;
if (KWQNamesMatch(slotName, SIGNAL(slotFinishedParsing(bool, const QString &))))
return (void*)&SVGDocumentImpl::slotFinishedParsing;

return QObject::slotFunctionPtr(slotName);
}
</x-tad-bigger>
2- replace the <x-tad-bigger>int</x-tad-bigger><x-tad-bigger> m_function</x-tad-bigger> member attribute in KWQSlot which is the index of the slot function refering to <x-tad-bigger>enum</x-tad-bigger><x-tad-bigger> FunctionNumber</x-tad-bigger> by a <x-tad-bigger>void</x-tad-bigger><x-tad-bigger> *m_functionPtr</x-tad-bigger> or <x-tad-bigger>void</x-tad-bigger><x-tad-bigger> (QObject::*m_functionPtr)()</x-tad-bigger> that would be the address of the slot method. Make KWQSignal a friend of KWQSlot so it can access both attributes.

This implies modifying the KWQSlot constructor, and QObject::connect:
<x-tad-bigger> signal->connect(KWQSlot(</x-tad-bigger><x-tad-bigger>const_cast</x-tad-bigger><x-tad-bigger><QObject *>(receiver), receiver->slotFunctionPtr(member)));
</x-tad-bigger>instead of:
<x-tad-bigger> signal->connect(KWQSlot(</x-tad-bigger><x-tad-bigger>const_cast</x-tad-bigger><x-tad-bigger><QObject *>(receiver), member));
</x-tad-bigger>All the <x-tad-bigger>call</x-tad-bigger> methods in KWQSlot are no longer needed.

3- add a unique signal dispatching method to KWQSignal called from the signaling methods. This method gets the target object and member slot function from each registered KWQSlot and call that function with the replicated arguments. A possible implementation uses gcc builtin functions <x-tad-bigger>__builtin_apply_args</x-tad-bigger> and <x-tad-bigger>__builtin_apply</x-tad-bigger> that allows a caller function to call another function with the arguments it received.
<x-tad-bigger>
void</x-tad-bigger><x-tad-bigger> KWQSignal::dispatchSignal() </x-tad-bigger><x-tad-bigger>const</x-tad-bigger><x-tad-bigger>
{

</x-tad-bigger><x-tad-bigger>if</x-tad-bigger><x-tad-bigger> (!_object->_signalsBlocked) {
KWQObjectSenderScope senderScope(_object);
QValueList<KWQSlot> copiedSlots(_slots);
QValueListConstIterator<KWQSlot> end = copiedSlots.end();

</x-tad-bigger><x-tad-bigger>for</x-tad-bigger><x-tad-bigger> (QValueListConstIterator<KWQSlot> it = copiedSlots.begin(); it != end; ++it) {
KWQSlot *slot = &(*it);

</x-tad-bigger><x-tad-bigger>if</x-tad-bigger><x-tad-bigger> (slot->m_functionPtr && slot->m_object) {</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger> </x-tad-bigger><x-tad-bigger>// Copy the arguments to the stack</x-tad-bigger><x-tad-bigger>
</x-tad-bigger><x-tad-bigger>int</x-tad-bigger><x-tad-bigger> *arguments = __builtin_apply_args();
</x-tad-bigger><x-tad-bigger>// Change the first argument (this) to the target object</x-tad-bigger><x-tad-bigger>
arguments[</x-tad-bigger><x-tad-bigger>1</x-tad-bigger><x-tad-bigger>] = slot->m_object.pointer();
</x-tad-bigger><x-tad-bigger>// Apply the slot method to the target object with the initial arguments</x-tad-bigger><x-tad-bigger>
__builtin_apply(slot->m_functionPtr, arguments, </x-tad-bigger><x-tad-bigger>32</x-tad-bigger><x-tad-bigger>);
}
}
}
}
</x-tad-bigger>
I'm not sure what value should have the third arg of <x-tad-bigger>__builtin_apply</x-tad-bigger>, <x-tad-bigger>32</x-tad-bigger> is random.

4- make the signaling functions call the unique signal dispatch method:

<x-tad-bigger> void KSVG::SVGDocumentImpl::finishedParsing(bool error, const QString &errorDesc)
{
void (*call) (KWQSignal *, bool, const QString &) =
(void (*)(KWQSignal *, bool, const QString &))&KWQSignal::dispatchSignal;
call(&_finishedParsing, error, errorDesc);
}
</x-tad-bigger>

The calling scheme is then:

<x-tad-bigger>Sender KWQSignal Target1
| | |
->|signal(arg1Type arg1, arg2Type arg2...) |
| | |
| | |
| | |
|-------------->|dispatchSignal(arg1Type arg1, arg2Type arg2...)
| | |
| | |
| |(for each KWQSlot: |
| |copy received args |
| |--------------------------->|slot(arg1Type arg1, arg2Type arg2...)
| | |
| | |
| | |
| | |
| | |
</x-tad-bigger>
KWQSlot is only used as a storage for the target object and function pointers.

This scheme still lacks some features like slots access rights (public/protected/private) and argument type checking. But at least it has proven to be usable and there's no need to rebuild WebCore for new kinds of connect wires.

Please feel free to comment,

Nicolas Normand
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webcore-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webcore-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.