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

[Gabriele Kahlout]

>
> 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.
>

hmm.. only if you want serial execution (1.), but not concurrent (most
desirable, every time possible, especially in networking).

>
> > 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?
>

Fairness /concurrency. It's undesirable to have the 2nd client wait until
those who came first are completely served.


> > > 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.
>

So the primary relevant issue here is that it's connectionless,  but faster
(& unreliable). However as quoted above AbstractSocket should abstract
enough. Instead of listen bind (QUdpSocket::DontShareAddress ).
I want to transfer images as fast as possible. I don't think desktop sharing
(for instance) would use TCP.

The trouble is with virtual connection. How do I 'imitate' this with
QAbstractSocket/UDP?

>
> > >        QTcpSocket *clientSocket = listener->nextPendingConnection();
>
//while(waitForReadyRead(-1)){ //I prefer blocking. "A blocking socket
doesn't require an event loop and typically leads to simpler code".
and then??
new ClientHandler(serverSocket.localAddress(), serverSocket.localPort())
(used by the clientHandler to create a new socket? )


> 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.
>

blocking + threading,  gui + slots.


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

How come what about  clientHandler.start()?

>
> > > 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.
>

To achieve concurrency you still need clientHandler.


> (Hint: get a mail reader that strips the signatures off)
>

My client (gmail web interface) collapses all the 'footer' stuff of emails I
reply into  "- Zitierten Text anzeigen -".

-- 
Regards,
K. Gabriele

--- unchanged since 25/1/10 ---
P.S. Unless a notification (LON), please reply either with an answer OR with
" ACK" appended to this subject within 48 hours. Otherwise, I might resend.
In(LON, this) ∨ In(48h, TimeNow) ∨ ∃x. In(x, MyInbox) ∧ IsAnswerTo(x, this)
∨ (In(subject(this), subject(x)) ∧ In(ACK, subject(x)) ∧
¬IsAnswerTo(x,this)) ⇒ ¬IResend(this).

Also note that correspondence may be received only from specified a priori
senders, or if the subject of this email ends with a code, eg. -LICHT01X,
then also from senders whose reply contains it.
∀x. In(x, MyInbox) ⇒ In(senderAddress(x), MySafeSenderList) ∨ (∃y. In(y,
subject(this) ) ∧ In(y,x) ∧ isCodeLike(y, -LICHT01X) ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100512/25f1e5d3/attachment.html