[mythtv] MythSocket class

[John P Poet]

On 5/28/06, John P Poet <jppoet at gmail.com> wrote:
> On 5/27/06, Isaac Richards <ijr at case.edu> wrote:
> > On Monday 01 May 2006 10:59 pm, Jim Westfall wrote:
> > > Jim Westfall <jwestfall at surrealistic.net> wrote [04.19.06]:
> > > > I wasnt able to reproduce the slave backend issue in testing.  I have an
> > > > updated patch I will try and get submitted this weekend.  It addresses
> > > > the backend worker thread hack and expands the conversion to include
> > > > mythcontext and a few other classes that use QSocket[Device].
> > >
> > > Here is the updated version.
> > >
> > > I ended up stripping out QSocketNotifier and replaced it with an internal
> > > thread to monitor the socket.  The thread will only be started if
> > > callbacks are setup.  I setup the callbacks to be similar to how daniel
> > > did them with streamlisteners.  It should be possible to ditch qobject
> > > once something is done with the background connect() code.
> > >
> > > On the backend I removed all the worker thread code and am letting the
> > > MythSocket thread handle processing the requests via the readyRead
> > > callback.  There are still a few things that need to be worked out.  Each
> > > new thread costs 7-10megs of memory and there is a 30 second delay when
> > > deleting playback objects.  This can lead to large memory usage if someone
> > > is triggering alot of file transfers (ie xfering png images, while
> > > browsing recorded list).  There is also no limit on the number of threads
> > > that can concurrently be processing requests, this was mostly limited to
> > > 5 before with the worker threads.
> >
> > I've updated this patch to take care of the remaining issues Jim outlined
> > above (one thread to do all the select()ing, and keep the threadpool in the
> > backend around for processing).  I'd appreciate testers - I don't have a
> > slave backend (and can't easily set one up) to test against.  I'd like to
> > commit this next weekend, if possible.  Things seem to work pretty well,
> > though, from what I can see.
> >
> > mythsocket4.diff was generated against revision 10051, and you'll need
> > something fairly recent for it to work.
> >
> > Isaac
>
> I grabbed version 10051 and applied these patches.  I then started up
> recordings on most of my tuners.
>
<snip>

Forgot to mention...

I had to add an include of assert.h in mythsocket.cpp on my Fedora
Core 5 machine.  This was not necessary on my Fedora Core 4 box.

Also, I had to disable a VERBOSE:

Index: libs/libmythtv/dvbrecorder.cpp
===================================================================
--- libs/libmythtv/dvbrecorder.cpp	(revision 10051)
+++ libs/libmythtv/dvbrecorder.cpp	(working copy)
@@ -614,9 +614,11 @@
     {
         QMutexLocker read_lock(&_pid_lock);

+#if 0
         VERBOSE(VB_IMPORTANT, "Writing PAT & PMT @"
                 <<ringBuffer->GetWritePosition()<<" + "
                 <<(_payload_buffer.size()*188));
+#endif

         uint next_cc;
         if (_pat && _pmt && ringBuffer)
===================================================================

To keep it from saturating my logs.

John