[mythtv] MythSocket class

Jim Westfall jwestfall at surrealistic.net
Wed Apr 5 21:09:26 UTC 2006


Isaac Richards <ijr at case.edu> wrote [04.05.06]:
> On Wednesday 05 April 2006 10:55, Jim Westfall wrote:
> > Isaac Richards <ijr at case.edu> wrote [04.05.06]:
> > > On Tuesday 04 April 2006 21:08, Jim Westfall wrote:
> > > > Hi
> > > >
> > > > I took a stab at making a MythSocket class that was talked about
> > > > briefly last week.  Attached is what I have thus far.
> > > >
> > > > mythsocket.diff - main patch that adds MythSocket into libmyth without
> > > > converting anything else.  Its based on QSocketDevice and adds
> > > > readyRead, connectionClosed, connected, and connectionFailed callbacks.
> > > >  It also has a connectToHost() function like QSocket to background the
> > > > connect() process.  I still need to add dns lookup support.
> > >
> > > I think I'd prefer an object that wasn't a QObject and didn't use a
> > > QSocketNotifier.  That's what's causing problems with using QSocket now.
> >
> > hrm I thought it was strictly a QSocket not being thread safe issue. 
> > Multiple calls to any of its functions that adjust its internal buffer can
> > result in a crash.
> 
> I've seen bunches of crashes due to the QSocketNotifier as well.  However, it 
> may be ok if we add qApp->lock/unlock around those (un)registerSocketNotifier 
> calls..  I think the crashes were probably from QSocket weirdness (it tends 
> to occasionally add multiple notifiers of the same type for the same socket, 
> which seems to go horribly wrong).
> 
> > How would you go about doing it then?  Have MythSocket create a thread
> > and monitor (select()) its own socket?
> 
> Something like that, yeah.  Let's try what you have, first, just with some 
> additional locking, and adding refcounting to the class, too..
> 

Ok, I will try and add locking and refcounts this weekend.  I assume there 
would also be no objecting to pulling in read/writestringlist functions?

thx
jim


More information about the mythtv-dev mailing list