[Qt-interest] Data exchange in threads
Tony Rietwyk
tony.rietwyk at rightsoft.com.au
Fri Apr 29 10:25:37 CEST 2011
Hi Alex,
Yes, I understand that cross thread signals use events internally. In this case, the OP was asking for something more efficient to go from the server back to one specific thread - instead of broadcasting to all of the them.
Regards,
Tony.
> -----Original Message-----
> From:
> qt-interest-bounces+tony.rietwyk=rightsoft.com.au at qt.nokia.com
>
> [mailto:qt-interest-bounces+tony.rietwyk=rightsoft.com.au at qt.n
> okia.com] On Behalf Of Malyushytsky, Alex
> Sent: Friday, 29 April 2011 17:36 PM
> To: qt-interest at trolltech.com
> Subject: Re: [Qt-interest] Data exchange in threads
>
>
> 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.”
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1209 / Virus Database: 1500/3603 - Release
> Date: 04/28/11
>
More information about the Qt-interest-old
mailing list