PDA

View Full Version : Publish Subscriber Pattern in Qt



donglebob
3rd February 2009, 08:01
Hi,

I have a publisher thread and a few subscriber threads.
The number of subscribers changes at runtime.

In my current implemenation the publisher creates the subscriber threads...this is maybe not the best way...

I need a example how to implement this pattern with Qt.

Hope you can help me..

Edit:

The informtion which needs to be delivered is most of the the time received just by one subscriber. But in case of a "broadcast" every subscribers will receive it.

Where is the difference between the Observer pattern and the publish/subscriber .
http://msdn.microsoft.com/en-us/library/ms978603.aspx

caduel
3rd February 2009, 10:37
just use signals & slots across threads (Qt4)

donglebob
3rd February 2009, 10:44
But this is Observer what you mean.

What I have implemented is the following:
My Publisher gets data from external,...checks the content and sends this data to the right subscriber.
When the content of the data includes an information to broadcast the incoming data.
It broadcast it to all subscribers.
When a subscriber is not known my publisher creates a new subscriber (thread).

I think that this is not Observer. Observer pattern sends every time the incoming data to all subscribers, without checking the content.

I think that what I made is the content-based Publish Subscriber model.
But I am not sure if this is the right name for it....I need to define it in my thesis.

Can someone give me a hint?

donglebob
3rd February 2009, 13:36
I think I mixed there something.

There is a publisher/subscriber design pattern and a publish/subscribe messaging model.
http://en.wikipedia.org/wiki/Publish/subscribe

What I mean is not the design pattern...

caduel
3rd February 2009, 14:27
Well, if you want to send the data only to *some* of the subscribers, then a signal won't do the job. (Which is too bad, since a signal would have solved all threading issues.)

In this case you have to check the "message" (inside the publisher) for each subscriber. This is easy since it does not have to do with threads.
Once you know if a specific publisher gets the message, you "just" send him the message. This is the interesting part. There are various possibilites:
* post an event to the receiving object (posting events in QCoreApplication is thread safe)
* have all subscribers provide a thread-safe callback
* there certainly are more ways to do that...

The 'right' choice depends on your concrete requirements.

HTH

donglebob
3rd February 2009, 14:45
Thats what I have done already.
I send the data after analyzing it. The data has something like a destination address.
With this address I can look into a list and get the pointer to the right receiving thread.

With this information I can connect my sending signal from the publisher with the slot of the subscriber. And send the data....
This procedure will be repeated for every data received.

This way of providing data to the subscribers looks similar to the "publish/subscriber messaging model"
But in my case there is one difference....my publisher creates the subscribers itself..and that means he registers them.

My question is now...can I call what I did publish/subscriber messaging or not?
Or is this another kind of messaging model?

donglebob
4th February 2009, 08:39
Anyone out there who can give me a hint?

rwtmoore@hotmail.com
21st June 2013, 20:05
I'm not 100% sure of what you're doing, but I may know enough to be helpful.

I think what you are doing is pub/sub; I don't think it matters who creates the subs.

I don't know the particulars of your subs. Do you know the max number? Do you know the names of the objects ahead of time?

If the answer to the above 2 questions is yes, I can suggest something.

Let's say you have 3 objects that can subscribe to a publisher. Or put another way, 3 slots that can possibly be connected to a signal. That means there are 7 possible combinations. That means you can have 7 signals each with their own corresponding connect to a slot or slots.

bool QObject::connect(ptrPublisher, SIGNAL(Signal_1(), ptrSubscriber, SLOT(Slot_1() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_2(), ptrSubscriber, SLOT(Slot_2() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_3(), ptrSubscriber, SLOT(Slot_3() );

bool QObject::connect(ptrPublisher, SIGNAL(Signal_4(), ptrSubscriber, SLOT(Slot_1() );
bool QObject::connect(ptrPublisher, SIGNAL(Signal_4(), ptrSubscriber, SLOT(Slot_2() );

etc.


Possible slots: (1), (2), (3), (1,2), (1,3), (2,3), (1,2,3)


How you determine which slots are to be connected is up to you (if-else, switch statement, etc.)

When you determine which slots are to be connected, just emit the appropriate signal.

d_stranz
23rd June 2013, 23:04
I'm sure this answer was very helpful, seeing as how you posted it over 4 years after the original thread was started.

rwtmoore@hotmail.com
26th June 2013, 16:01
I know at least one person read it...