[Qt-interest] Can two thread share a QAbstractSocket?

[Thiago Macieira]

Em Quarta-feira 12. Maio 2010, às 20.00.16, Gabriele Kahlout escreveu:
> > First, I have to question why you need a thread at all. What kind of
> > operations do you plan on doing that require a thread?
> 
> Transfer images. So a client may tell the server, send this
> image/screenshot (QByteArray?) to X. Who should receive and serve this
> call? In the arcitecture I'm familiar to (the java code) a separate thread
> handles all of that.

You need to learn networking, not Java networking.

Qt allows you to do networking without blocking. So networking doesn't require 
threads: that's why I asked what *else* you were doing that required threads.

> 1. Single thread serving all requests: slow, while a client requested only
> to 'login' or a small image, it must wait before a long one of another is
> sent. Also, confusing.

And where's the need for thread here? Sure, it takes time to transfer. But so 
what?

> > UDP has no "accept". So I will assume you meant TCP servers.
> 
> True this code is TCP. However, I'd like to use UDP now, hoping to exploit
> that "QAbstractSocket's API unifies most of the differences between the two
> protocols".

I don't think you understand UDP. Please study it before thinking that it 
serves your purpose.

> > void SomeObject::slotNewConnection()
> > {
> > 
> >        QTcpSocket *clientSocket = listener->nextPendingConnection();
> >        ClientHandler *handler = new ClientHandler;
> 
>        clientSocket->moveToThread(handler);
> 
> 
>  handler->start(); // in my code i put this at the end of the constructor.
> Not recommended?

Doesn't make any difference. Do as you wish.

> > void ClientHandler::run()
> > {
> > 
> >        SomeOtherObject obj;
> 
> //Why is this needed? Wouldn't  " this-> " do too?

No. Because of this:

> 
> >        obj.connect(clientSocket, SIGNAL(readyRead()),
> > 
> > SLOT(slotReadyRead()));

Since obj was created in the ClientHandler thread, its slot is delivered in 
that thread too.

The "this" object was created in another thread. Therefore, an AutoConnection 
becomes queued, and the slot is delivered back in the main thread.

You can change it to DirectConnection. I'm using a separate object here to 
make it perfectly clear to you: this is the most common error people make when 
using threads along with signals and slots.

> //or waitForReadyRead().

That's blocking, and you won't need the slot.

But the code I designed, I did it so that it won't need threads.

> > Note that the threading bits in my code are completely unnecessary.
> 
> // u mean the  SomeOtherObject stuff?

No, I mean the threading. The SomeOtherObject is necessary to receive the 
readyRead() signal.

> > PS: please exercise quoting in your replies to emails.
> 
> What do you mean? I know quoting to mean using quotes "", and to cite
> authors of works I refer to. What's the issue here?

I mean the quoting of the email you're replying to (all these lines starting 
with >). Do diet-quotes: quote only what you need, delete the rest. Especially 
signatures. (Hint: get a mail reader that strips the signatures off)

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100512/6ddb7088/attachment.bin