[mythtv] MythSocket class

John P Poet jppoet at gmail.com
Thu May 4 15:43:15 UTC 2006


On 5/1/06, Jim Westfall <jwestfall at surrealistic.net> 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.
>
> Also a small patch for mythdvd since it was using mythcontext.h to get its
> qsocket.h include.
>
> jim


Cool!  Thanks for your work on this.  I will try it this weekend.

John


More information about the mythtv-dev mailing list