[Development] QTcpSocket, QLocalSocket, common-use-model?
Thiago Macieira
thiago.macieira at intel.com
Tue Oct 9 18:59:09 CEST 2012
On terça-feira, 9 de outubro de 2012 17.27.52, Joerg Bornemann wrote:
> On 09/10/2012 15:12, Giuseppe D'Angelo wrote:
> >> There's AFAIK no "short cut" for pure localhost TCP
> >> connections.
> >
> > There are. For instance, checksums are not computed nor checked for
> > packets travelling through the loopback interface.
>
> But there's still more overhead (e.g. context switches) compared to pipe
> / domain socket connections, right?
Not more context switches. They are exactly the same, since it goes from one
application, through the kernel, to the other application. In the best case
scenario, that's exactly one partial context switch (into kernel mode) and one
full context switch (into the other application).
[In the common scenario, the second application will not be scheduled yet, so
the kernel will return to the sender and context-switch later.]
The question is only whether there's more overhead in kernel mode. A quick
check over the cubicle wall here answers that there is a little overhead more
with TCP, since it must still verify the netfilter rules (think iptables).
The decreasing overhead order is like this:
TCP sockets non-loopback
TCP sockets loopback
Unix sockets
pipe
eventfd
Remember that sockets are full-duplex, whereas a pipe is only half-duplex, so
you need two pipes to achieve the same bidirectional communication that
sockets do. And eventfd only supports a simple integer increment or semaphore
posting (its ideal usecase is waking up threads).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121009/cf0dea43/attachment.sig>
More information about the Development
mailing list