[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