> 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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
