On Saturday 12 March 2005 12:19 pm, Anduin Withers wrote: > I believe the eventual answer is to abandon Qt's sockets wrapper, > I tried calling the app event loop before the sleep, while this does get > the endConnection notification this isn't enough. I went a little further > and it actually isn't making it as far as I thought. There is a lock > problem, only in this case it is a QApplication lock. When the readSocket > signal is called the application lock is active, as ReadStringList locks > the app while waiting for data, there is a situation where all pool threads > can be waiting on the application lock, which will never be released as > readSocket won't return.
Well, we could switch to using QSocketDevice for the backend (like the frontend uses). It's basically just a portable wrapper around the socket code, instead of the whole event-loop-needing QSocket class. We'd be able to just do a select() on the fds that way, I think. Probably need to spawn off a subthread to do the main socket handling that way, though. Isaac _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
