[mythtv] [mythtv-commits] Ticket #1381: Slow keyboard response over

Mark Buechler mark.buechler at gmail.com
Sun Feb 26 19:49:45 UTC 2006


How is it that some people truly feel that free software developers owe them
something? I would think they'd be grateful the code has been released for
their use at all! People need to stop bitching about things which they get
for free.

- Mark.

On 2/25/06, mythtv at zacglen.com.au <mythtv at zacglen.com.au> wrote:
>
> >> >> >We might be waiting for a while.  There's no such select() (or
> similar
> >> >> > stuff)
> >> >> >
> >> >> >in the code that could be causing that. =)
> >> >>
> >> >> Yes, there is.
> >> >> Try an strace and find out the *truth*.
> >> >>
> >> >> Anyone who has done any programming (like myself) will know
> >> >> that QEventLoop()::exec invokes select().
> >> >
> >> >I didn't realize that I had to specifically put "in mythtv" in that
> >> > sentenc e,
> >> >
> >> >since this is the mythtv mailing list & bug tracker and not the Qt
> one.
> >> >
> >> >Silly me.
> >> >
> >> >> This is probably a major top-level design error.
> >> >
> >> >That only happens to a few people?  That's highly doubtful.
> >>
> >> Really? So top level design flaws always immediate manifest themselves
> >> and are instantly corrected?
> >
> >A 'major top-level design error' would generally be happening to more
> than
> >2
> >
> >people.  You're 0 for 3 so far in coming up with ideas as to this 'major
> >
> >design' issue.
> >
> >> Anyhow, for all those doubters out there, here are some stack traces.
> >>
> >> A)
> >> #0  0x05449490 in select () from /lib/libc.so.6
> >> #1  0x07173b68 in QEventLoop::processEvents () from
> >> /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2  0x071e222b in
> QEventLoop::enterLoop
> >> () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #3  0x071c94cf in
> >> QApplication::enter_loop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #4
> >
> >> 0x045a750d in MythDialog::exec () from /usr/lib/libmyth-0.19.so.0 #5
> >
> >> 0x0806497d in RunMenu (themedir=@0xbfd2b100) at main.cpp:498
> >> #6  0x0806c93a in main (argc=1, argv=0xbfd2b1b4) at main.cpp:1062
> >
> >Wow, look at that, a select() in Qt.  How's that mean it's a 'major
> top-lev
> >el
> >
> >design error' in mythtv, again?  I'm confused, please explain.  Remember,
> y
> >ou
> >
> >said:
> >
> >"But isn't is quite possible that there is some flakey code which is
> causin
> >g
> >
> >keystroke events to only be processed after the select() times out?"
> >
> >To which the answer was, and still is: 'no, it's not possible, since no
> suc
> >h
> >
> >code exists in mythtv.'  This doesn't mean that 'there are no selects()
> use
> >d
> >
> >anywhere, ever, when running mythtv'.  That would just be stupid, and
> >
> >interpreting that statement like that, which you've apparently chosen to
> do
> >,
> >
> >is even sillier.
> >
> >Yes, Qt uses a select() to know when to wake up and process events.  This
> h
> >as
> >
> >absolutely nothing to do with the code, or the design of code, in myth
> >
> >itself.  If you believe there is a bug in that part of Qt, which is
> _ever_
> >so
> >
> >slightly doubtful, take it up with Trolltech, not us.
>
> Ok, so in your view everything is _ever_ so slightly doubtful.
> In your world there is no bug in MythTV, and none in Qt either.
> I am very happy for you.
>
> >
> >> B)
> >>
> >> > #0  0x05449490 in select () from /lib/libc.so.6
> >> > #1  0x07450f48 in QSocketDevice::waitForMore () from
> >> > /usr/lib/qt-3.3/lib/libqt-mt.so.3 #2  0x0478db0d in
> SipFsm::CheckRxEvent
> >> > () from /usr/lib/mythtv/plugins/libmythphone.so #3  0x047911e2 in
> >> > SipThread::CheckNetworkEvents () from
> >> > /usr/lib/mythtv/plugins/libmythphone.so #4  0x04792b27 in
> >> > SipThread::SipThreadWorker () from
> >> > /usr/lib/mythtv/plugins/libmythphone.so #5  0x04792fbb in
> SipThread::run
> >> > () from /usr/lib/mythtv/plugins/libmythphone.so #6  0x071c2378 in
> >> > QThreadInstance::start () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #7
> >
> >> > 0x00373947 in start_thread () from /lib/libpthread.so.0
> >> > #8  0x054502ce in clone () from /lib/libc.so.6
> >
> >Wow, another select(), but lookithat, it's in a separate thread that has
> >
> >nothing to do with input processing.  Crazy, that.
>
> Here you go again! "Nothing to do with input processing".
> Everything that runs on same CPU can affect input processing!
> Try running:
>         dd if=/dev/zero of=/file1 &
>         dd if=/dev/zero of=/video/file2 &
> Then check your keystroke response time.
>
> But I am very pleased that I have wowed you and sent you crazy.
>
> >
> >Might as well point out the joystick code's select() too, but <gasp>
> that's
> >
> >also happening in a separate thread and won't impact keypress processing
> at
> >
> >all, either.
>
> Rubbish.
> Just because something is running in another thread doesn't insulate
> it from affecting any other thread.
> Anybody who has written a program would know that.
> It depends entirely on what your stupid threads are up to - and
> what other threads they might be blocking.
>
> I cannot believe how ignorant some so-called developers can be!
>
> >
> >> Goodness knows what the 'mythphone' stuff is trying to do - call home
> >> I suppose. I have it disabled so why doesn't it just close itself and
> die?
> >
> >You don't have it disabled, since it's obviously running and installed.
> >
> >Remove the plugin to disable it.  I never got around to making a way to
> >
> >disable a plugin aside from not installing it.
>
> It is already disabled.
>
> >
> >> Anyhow I figure that there might be excessive traffic from creating
> >> new pixmaps when a menu selection highlighting needs to change.
> >> But shouldn't they already exist as offscreen pixmaps?
> >> That would certainly be much more efficient, not to mention faster.
> >
> >All the pixmaps for the menus are loaded + scaled when the menu xml files
> a
> >re
> >
> >parsed at the start of the program, or when the user changes something in
> t
> >he
> >
> >appearance settings.  All it does when the current selection changes is
> dra
> >w
> >
> >different stuff (which, incidentally, can be fairly slow depending on
> your
> >
> >chosen resolution, what theme you're using, and if your X server has
> limite
> >d
> >
> >amounts of accel for blending pixmaps).  It only redraws the section of
> the
> >
> >screen that's needed, as well.  You might want to try actually looking at
> t
> >he
> >
> >source to see what it's doing.  It's not like profiling stuff like this
> is
> >
> >difficult.
> >
>
> I have decided to drop MythTv because it seems to be essentially
> reinventing
> the wheel.  Besides a scheduler which knows how to assign non-overlapping
> events to hardware, all interfacing can just as easily be done
> via a browser.
>
> And the advantages a browser has are:
>
> a) They already exist and are well tested and relatively bug-free.
> b) A remote client can do big fonts with minimum of HTML coding.
> c) It kills two birds with one stone - true media convergence (non-myth).
> d) I am sure there are plenty more reasons.
>
> Besides, I can also arrange for the recorded files to be in whatever
> format I wish, with/without any processing of my choosing.
>
> Additionally I can totally avoid a database and use a simple filesystem
> based scheme. I have already drawn on up on the back of an envelope.
> I prefer configurations to be in plain files anyhow.
>
> Have a nice development experience.
> Bye.
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060226/000d1df9/attachment.htm 


More information about the mythtv-dev mailing list