[Qt-interest] Data exchange in threads

[Malyushytsky, Alex]

AFAIK signal/slot mechanics is using events internally in case of Qt::QueuedConnection.
So at least there is no point to use Event instead cause you use lose flexibility.

Just 1 cent.

Alex


-----Original Message-----
From: qt-interest-bounces+alex=wai.com at qt.nokia.com [mailto:qt-interest-bounces+alex=wai.com at qt.nokia.com] On Behalf Of Tony Rietwyk
Sent: Thursday, April 28, 2011 8:37 PM
To: qt-interest at trolltech.com
Subject: Re: [Qt-interest] Data exchange in threads

Hi Nick,

Instead of using signals to send back to the threads, have you tried using QCoreApplication::postEvent with your own QEvent, posted to an object that is created inside the run method of each thread?  The docs are not at all clear about this - they just say that the event will be put into 'an event loop'.  I assume this will be the thread's event loop, if the receiver object has been created within the thread.  Your server would have something like:

MyServer::receiveMessage(threadIs, message)
{
        // Process message...

        // Send result back to thread...
        MyThread *thread = threadMap.value( threadId );
        MyEvent *event = new MyEvent( result );
        qApp->postEvent( thread->objectMember, event );
}

The thread's objectMember would look for MyEvent in its event method override.

You could even use the same method for thread to server instead of signals.

Hope that helps,

Tony.

> -----Original Message-----
> Sent: Friday, 29 April 2011 08:45 AM
>
> So, how I did this.
>
> When server create new thread, he connect thread's signal
> emitMessage(threadId, message) to server's slot
> receiveMessage(threadId,
> message) and server's signal emitMessage(threadId, message)
> to thread's
> slot receiveMessage(threadId, message).
> So, when thread need to send message to another thread, he
> emit signal
> emitMessage with sending message and receiver's id to server.
> Server catch
> signal and emit signal to all threads. All threads compare
> their ids with
> threadId from signal and if its matching do something with
> this message.
> It's works, but I have doubts about performance of this
> method. I hope my
> system will be used by millions people and maybe exists more
> comfortable
> and performance method?
>
> Best regards,
> Nick.
>
> Tue, 26 Apr 2011 16:54:49 +0300 було написано BRM
> <bm_witness at yahoo.com>:
>
> > There are numerous ways, which is best depends on what you
> are doing.
> >
> > 1. Use a modified signal/slot:
> > - include a 'client ID' in the signal
> > - the network connection is wrapped such that it knows its
> 'client ID'
> > - only forwards data to the client if the client ID matches.
> >
> > 2. Use dedicated objects with signals/slots
> > - each object interfaces for the entire session of the client,
> > interfacing to
> > the internal parts as necessary, not necessarily with
> signals/slots.
> > This will
> > require locks/etc.
> > - each object has a normal signal/slot interface to the
> client it is
> > servicing.
> >
> > 3. QObject->sender()
> > - when you receive a call to a certain slot, get the signal
> sender,
> > generate the
> > result and then send it back only to the sender.
> > - this requires that the sender() be able to be
> qobject_cast<>() to a
> > known
> > QObject derived class with a known interface (slot) to send
> the data
> > back on.
> >
> > I have used #3 for certain tasks. #2 may be more to your
> fitting, but it
> > certainly the harder method in most cases since you have to
> figure out
> > the
> > locks, etc and you can't take full advantage of signals/slots.
> >
> > So as I said - it's a matter of your system design and what
> works best.
> > For me,
> > #3 was a simple enough solution for something where I
> wanted one client
> > to have
> > total control of a multi-message process but it's not necessarily
> > correct for
> > you - and it certainly breaks signal-slot OO practices
> (since you're not
> > really
> > suppose to care who calls a slot).
> >
> > $0.02
> >
> > Ben
> >
> >
> >
> > ----- Original Message ----
> >> From: Николай Шатохин <n.shatokhin at gmail.com>
> >> To: "qt-interest at qt.nokia.com" <Qt-interest at qt.nokia.com>
> >> Sent: Tue, April 26, 2011 9:02:48 AM
> >> Subject: [Qt-interest] Data exchange in threads
> >>
> >> Hello.
> >>
> >> I have one server on qt4, one client on qt4 and entry
> point on  php.
> >>
> >> Client can send data to php by json and send data to server  (this
> >> action dynamically create new thread on server). Php can
> send data  on
> >> server too (it's no difference for server who send data).
> So we  have
> >> two thread created dynamically - one for client, one for
> entry  (this
> >> threads on server can be thousands or millions). So, how
> can  entry's
> >> thread send data only for this client's thread? If I'll  you
> >> signals/slot, all threads send data to all threads and all  threads
> >> must do checking (it's signal for me or not?). It's very
> slow. So,  can
> >> I use some quick  method?

_______________________________________________
Qt-interest mailing list
Qt-interest at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-interest


---------------------------------------------------------------------------------------------------
Weidlinger Associates, Inc. made the following annotations.

“This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you.”

“Please consider our environment before printing this email.”