[Qt-interest] sockets and threads on linux

[Francisco Gonzalez]

In your implementation details both signal readyRead() and slot onReadyRead() 
are members of your MyTcpSocket class, so when you move the pSocket object to 
the QThread th, you are moving both the signal, and the processing function.
I do not understand how can it improve the socket capability of processing, as 
both functions live in the same thread.

On Lunes, 14 de Febrero de 2011 10:19:17 pmqt71 escribió:
> I'm still learning Qt and I want to be aware of various way to do the
> work, so I'm going  to implement both solutions (single and multi-threaded
> socket I/O). Now I'm going to debug the readyRead signal not working on
> linux...
> Really appreciate your suggestions.
> pm.
> 
> 
> 
> 2011/2/14 Jason H <scorp1us at yahoo.com>
> 
> >  Thiago and I respectfully disagree on our philosophy to use threads when
> > 
> > using sockets.
> > He says never, and I say anything above the trivial.
> > 
> > The fully async behavior of Qt's implementation means you don't have to
> > use threads. You can do just fine without them... in most cases. And you
> > can do just fine when having a GUI in the same thread too.
> > 
> > I use threads anytime the request could take substantial CPU. For most
> > types of network traffic, when there is significant I/O delay or trivial
> > computation involved in the network data. There won't be a scalability
> > issue. (Serving a file will wait on disks for the most part, or it'll all
> > be in cache, either way, single thread is fine)
> > 
> > I however prefer to offer SSL/TLS everywhere, and having it multithreaded
> > will help distribute the encryption load over all cores. My computations
> > were lengthy in nature, could use compression if the client requested it.
> > For light loads (< 50 clients) I could serve at 80% to full speed. After
> > that, it dropped off. My specs required I be able to service within
> > specific time frames at higher loads, so I went multithreaded.
> > 
> > It's not much harder to make it multithreaded, so if I think I might want
> > it, then I do it from the start. If you're new and want to just get it
> > working, then it's not a mistake to keep it single threaded and cross
> > that bridge when you come to it.
> > 
> >  ------------------------------
> > 
> > *From:* pmqt71 <pmqt71 at gmail.com>
> > *To:* Thiago Macieira <thiago at kde.org>; qt-interest at trolltech.com
> > *Sent:* Sun, February 13, 2011 6:24:32 PM
> > *Subject:* Re: [Qt-interest] sockets and threads on linux
> > 
> > 
> > Hi Thiago,
> > I'd like to make the thread solution working in order to better
> > understand the related concepts with Qt.
> > It actually works on XP: threads, sockets, events... it's working very
> > well with hundreds of clients.
> > 
> >  Are you suggesting me to avoid threads with sockets for a
> > 
> > performance/optimization issue? or do you know about a possible problem?
> > 
> > thanks
> > pm
> > 
> > 2011/2/13 Thiago Macieira <thiago at kde.org>
> > 
> >> On Sunday, 13 de February de 2011 17:42:06 pmqt71 wrote:
> >> > Hi all,
> >> > Hi Qt people, I hope the best for Qt and you!
> >> > 
> >> > I have a tcp client server program working well on WinXP, but not on
> >> 
> >> linux.
> >> 
> >> > MyTcpServer inherits from QTcpServer. the incomingConnection method
> >> 
> >> creates
> >> 
> >> > a new socket and moves it to a new thread. The socket is handled by
> >> > MyTcpSocket that inherits from QTcpSocket and implements the slots to
> >> 
> >> manage
> >> 
> >> > client's incoming data:
> >> Why? Why do you insist in using threads for networking I/O after I told
> >> you
> >> last week that you don't need to?
> >> 
> >> Use the thread to do the actual processing of the data. Not for the
> >> networking.
> >> 
> >> > On linux (Ubuntu 9.04 64bit) the readyRead signal is not fired. The
> >> > incomingConnection is completed with no error, the pSocket objects
> >> > gets
> >> 
> >> the
> >> 
> >> > event ThreadChange related to the moveToThread operation. Nothing
> >> > else. How can I debug?
> >> > Qt 4.6.2
> >> 
> >> First of all, upgrade.
> >> 
> >> Second, debug the moveToThread call and check if the socket notifiers
> >> and the
> >> socket engine got moved to the other thread. While debugging
> >> moveToThread, you
> >> should be able to identify any children that got moved along with it.
> >> 
> >> Alternatively, or in addition, you can also put some breakpoints or
> >> debugging
> >> information in the register and unregisterSocketNotifier functions in
> >> the event
> >> dispatcher classes (QEventDispatcherUNIX or QEventDispatcherGlib). You
> >> should
> >> see the socket notifier be registered for the main thread, unregistered,
> >> then
> >> re-registered in the other thread.
> >> 
> >> --
> >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> >> 
> >>  Senior Product Manager - Nokia, Qt Development Frameworks
> >>  
> >>      PGP/GPG: 0x6EF45358; fingerprint:
> >>      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
> >> 
> >> _______________________________________________
> >> Qt-interest mailing list
> >> Qt-interest at qt.nokia.com
> >> http://lists.qt.nokia.com/mailman/listinfo/qt-interest