[Interest] Program runs only on four core processors.... sometimes.

[Guido Seifert]

> Now we assume it is a deadlock caused by some race conditions for some network 
> (socket?) resources. But maye it is simply because the data is sometimes wrong? 

Hi and good morning,
the data is never wrong. At least one point where I can be sure. :-)

> Imagine one service would send image data "worth 4 terrabytes" (because the "content 
> size field" was wrongly set, or the height/width fields), so what would your main 
> program do? Would it try to really create a QImage that large and hence be busy 
> allocating virtual memory?

Can't happen. I add images manually. An image that size would crash the gui long before it reaches the part, which causes the problems now. 

> That would be visible off course by its memory consumption which would grow and grow.

Memory is just fine. And I think such a huge image would tear down the whole system and not only the program.

> Off course my guess totally does not explain why it would (seem to) work on some 
> machines, and not on others (but that /could/ be a pure coincidence which would wrongly 
> lead us to believe it must be a threading/deadlock problem).

I think, it is Thiago's priority inversion. There are hints, which strongly point in that direction, e.g. I can unfreeze the main program when I kill one or two of its services. Discovered this yesterday. Now I have at least a fighting chance to fix the problem. Thanks, Thiago. :-)

Only thing is that I still don't _understand_ how this is possible at all. I write data in a QTcpSocket and expect result via readyRead(). I don't really need the results. Not really need means that nobody waits for them. If they don't come, old and inaccurat data is displayed. 

Is there a way that "qint64 QIODevice::write ( const QByteArray & byteArray )" does not return? If the peer can't receive the data? I'd expect the the tcp buffer is filled and when it is full a -1 is returned. What if the peer crashes? I'd also expect a return value of -1 and in both cases the main program continues.

>From my program logic I'd expect that it can slow down to a crawl, being too slow to be of any use, but it should do its work eventually and not permanently freeze. Even if I can fix the problem with some delays here and there to mitigate usage peaks, I'd love to unterstand what really happens.

Guido