[mythtv-commits] mythtv commit: r21608 by danielk

[mythtv at cvs.mythtv.org]

      Author: danielk
        Date: 2009-08-31 17:15:32 +0000 (Mon, 31 Aug 2009)
New Revision: 21608
   Changeset: http://cvs.mythtv.org/trac/changeset/21608

Modified:

   trunk/mythtv/libs/libmythdb/mythsocket.cpp
   trunk/mythtv/libs/libmythdb/mythsocket.h
   trunk/mythtv/libs/libmythdb/mythsocketthread.cpp
   trunk/mythtv/libs/libmythdb/mythsocketthread.h

Log:

Fixes #6516. This is the last of the mythsocket fixes sitting in my tree...

This speeds up worst case mythsocket handling. The worst case speedup is
entirely do to with the locking*, but we also use QWaitConditions for some
special cases, such as when starting up the socket handling loop and when
all sockets are closed, or when anonymous file descriptor pipes are not
available. This also adds some timing debug code at the -v socket,extra
level, but I left out most of the ones I used when optimising this code,
the remaning ones should be sufficient to locate any significant regressions
in the future.

This also gets rid of the special case stuff for MS Windows for which there
may need to be some additional header changes, but the code itself does work
when you inlcude compat.h. But compat.h shouldn't be included in any plugin
exported header files so I've left the header problem for someone with an
MS Windows system to work out (aside from fixing the select header problem
previously reported).

FYI [21589] provides a larger worst-case speedup, but in my testing both
changesets are needed to completely avoid timeouts.

* The main locking problem was just when we deleted sockets, this was
  treated as a rare occurance and we dropped and relocked the m_readyread_lock.
  But this would sometimes cause large enough delays to cause timeouts,
  which lead to more deleted sockets, causing more timeouts, etc.
  We now put these in a list and handle them later on when we've dropped
  the m_readyread_lock anyway for ready read data handling.
** A secondary locking problem had to do with our isLocked() handling,
   this was really a Qt4 port problem, the code was rewritten to work with
   Qt4 which dropped QMutex::locked(), but the new code was not very
   efficient.