[mythtv] MythSocket class
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?
More information about the mythtv-dev