[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