LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Fedora
User Name
Password
Fedora This forum is for the discussion of the Fedora Project.

Notices

Reply
 
Search this Thread
Old 04-29-2013, 06:14 AM   #4006
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76

Quote:
Originally Posted by daftcat View Post
Hmm, I like that much more than a system call to stty.
Except that it doesn't appear to work correctly. I suspect it is just consulting curses.COLS and curses.LINES variables which don't get updated automatically on resize event. Sticking with the stty call until I find something in the curses library that actually works.
 
Old 04-29-2013, 06:27 AM   #4007
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
SVN revision 456: Possible fix to resize the terminal window

As described in great detail above, the short story is that I use a system call to stty to determine the new values for lines and columns and then do the proper resizing of all three windows (main screen, statuswin, and titlewin) and the re-positioning of the status window.

Two caveats:

1. If current view is scoreboard or listings, a resize event moves the cursor back to the top of the records.
2. The code may still crash if the window is made smaller than 24x80.
 
Old 04-29-2013, 11:23 AM   #4008
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
Except that it doesn't appear to work correctly. I suspect it is just consulting curses.COLS and curses.LINES variables which don't get updated automatically on resize event. Sticking with the stty call until I find something in the curses library that actually works.
I doubt it consults curses.COLS and curses.LINES - tigetnum() is a terminfo call. Using tigetnum() seems to give off-by-one errors quite regularly if substituted for the stty calls in your code (that's what I notice anyway). It is this kind of thing that makes curses so frustrating. Anyway, your approach seems to be the way to go.

However there is still something odd going on even with the stty system calls, because if you do a lot of resizing of the window in a short period of time the select loop gets into an inconsistent state. This may be connected with the fact that SIGWINCH interrupts are causing some of the curses calls in the else block in the select exception handling code to return with an EINTR error. This can be demonstrated by putting a call to time.sleep(5) at the beginning of the else block: presumably what is happening is that the call to time.sleep() unblocks when a SIGWINCH interrupt arrives, although I am not sure why this does not itself result in an unhandled exception. As it happens including that sleep also helps mask the inconsistent state of the select loop.

I am not sure what to make of it.
 
Old 04-29-2013, 12:57 PM   #4009
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
OK. The attached patch is the best I can think of doing with this. It keeps the curses updates coming through at a rate that can be handled. It means that there can be up to a one second delay before the final sizing takes place but the effect is not horribly displeasing. As I suspected, it is necessary to block SIGWINCH while the wait is taking place. You might want to experiment with a smaller timeout.

It does not appear to be necessary to update curses.LINES and curses.COLS by hand as the call to resizeterm() seems to do that for you, but it appears harmless.

It seems to work pretty well with this patch.
 
Old 04-29-2013, 01:00 PM   #4010
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
Hmm, the patch was missing. Lets try again with a 'txt' ending.
Attached Files
File Type: txt signal2.txt (712 Bytes, 4 views)
 
Old 04-29-2013, 01:51 PM   #4011
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
Hmm, the patch was missing. Lets try again with a 'txt' ending.
I cannot reproduce the problem this is trying to fix, namely too many resizes in a short period causes a crash. Maybe my system is slow enough or maybe I'm just slow enough in resizing my windows. However, I think it looks kinda wonky to take a second to resize. User perception would be, "why does it take that long?" Can you try a time.sleep(0.5) and see if that also masks the problem you see?

I also wonder if we are trying to over-engineer this to be correct when good enough might be all it needs. When you perform resizing in your normal use case (e.g. not actively looking for a failure), do you still see crashes?
 
Old 04-29-2013, 04:37 PM   #4012
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
Interesting. On testing this further I see it is related to the speed of the machine. I have tested on a netbook and the effect is just about noticeable but limited and certainly not troublesome. On my dual core 3.3GHz sandybridge desktop it is very noticeable. I can reproduce it by taking the bottom right corner of the terminal window with the mouse, then waggling the bottom right corner around meaningfully with the mouse for about 3 or 4 seconds and then pressing an actionable key such as L or Q. The program does not usually crash (in the sense of end), although occasionally it does, but normally the event loop just goes wild and the only thing you can do is terminate the program with Ctrl-C or similar (Q ceases to work). It is difficult to describe - you have to see it really.

I have reduced the 1 second delay to 0.3 seconds and it is still effective in throttling the rate of interrupt events to avoid this. At 0.1 seconds I can just notice some artifacts, although they are not troublesome, and at 0.01 seconds it is as bad as not having a delay at all.

My desktop is fast but not super fast. It might be useful for someone with an 8 core machine to give it a try. Band aids for timing issues of this kind are a little worrying: my desktop is a little over 5 times faster than my netbook at doing things such as compiling kernels, but even so it is difficult to see why there should be this difference. I do not know a great deal of python (I am much more comfortable with C++, scheme or javascript) but I find python's wrapping of select puzzling as a whole. It is with the select wrapper where the problem may lie.
 
Old 04-29-2013, 06:08 PM   #4013
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
Interesting. On testing this further I see it is related to the speed of the machine. I have tested on a netbook and the effect is just about noticeable but limited and certainly not troublesome. On my dual core 3.3GHz sandybridge desktop it is very noticeable. I can reproduce it by taking the bottom right corner of the terminal window with the mouse, then waggling the bottom right corner around meaningfully with the mouse for about 3 or 4 seconds and then pressing an actionable key such as L or Q. The program does not usually crash (in the sense of end), although occasionally it does, but normally the event loop just goes wild and the only thing you can do is terminate the program with Ctrl-C or similar (Q ceases to work). It is difficult to describe - you have to see it really.

I have reduced the 1 second delay to 0.3 seconds and it is still effective in throttling the rate of interrupt events to avoid this. At 0.1 seconds I can just notice some artifacts, although they are not troublesome, and at 0.01 seconds it is as bad as not having a delay at all.

My desktop is fast but not super fast. It might be useful for someone with an 8 core machine to give it a try. Band aids for timing issues of this kind are a little worrying: my desktop is a little over 5 times faster than my netbook at doing things such as compiling kernels, but even so it is difficult to see why there should be this difference. I do not know a great deal of python (I am much more comfortable with C++, scheme or javascript) but I find python's wrapping of select puzzling as a whole. It is with the select wrapper where the problem may lie.
Okay, now I know how to reproduce it. But what seems troublesome is that because my machine is slower, I need a longer timer or the stty call gets interrupted. So I go back to the other question. Do you wiggle the corners often or are you doing it to try to solve a problem you know exists even though it may not be encountered through normal use?

On further testing, if 0.3 does it for you, I'll check in 0.5 which should cover most normal wiggling on even slower systems. I really have to give the corner a more-than-average shake to get it to crash. It's one of those things where I know the bug is there and I can shake it hard enough to break it. But I'm not likely to do so in my normal usage. I want to test it on a couple more systems at home before I check it in, though.

I think we can safely say that this is literally a corner case.
 
Old 04-29-2013, 07:18 PM   #4014
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
I am wiggling the window to test the code. Without the patch the problem might well be encountered with my fast machine in ordinary use but I cannot reproduce it in full on my slow machine even when trying hard.

If you still get the problem on a slow machine with a 0.5 second delay I think it can reasonably be called a corner case. What you say that the call to stty is "interrupted" maybe that could be solved by re-enabling interrupts after the call to mywin.getsize(), instead of before, but I have probably misunderstood what you meant.

I will fiddle with it some more tomorrow but I suspect we have gone as far as we can go within the (possible) limitations of pythons wrapping of select and curses.
 
Old 04-29-2013, 07:19 PM   #4015
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
Checked in 0.5 second delay because I needed to check in another fix for scrolling and master scoreboard view with odd number of viewable lines. Ironically, it was the PgUp() trick to keep master scoreboard and listwin synced up that was allowing records and cursors to take on odd values. All the more reason why I should focus on fixing the viewable area recalculation.
 
Old 04-29-2013, 07:57 PM   #4016
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
I am wiggling the window to test the code. Without the patch the problem might well be encountered with my fast machine in ordinary use but I cannot reproduce it in full on my slow machine even when trying hard.

If you still get the problem on a slow machine with a 0.5 second delay I think it can reasonably be called a corner case. What you say that the call to stty is "interrupted" maybe that could be solved by re-enabling interrupts after the call to mywin.getsize(), instead of before, but I have probably misunderstood what you meant.

I will fiddle with it some more tomorrow but I suspect we have gone as far as we can go within the (possible) limitations of pythons wrapping of select and curses.
Crash is here:

Code:
Traceback (most recent call last):
  File "./mlbviewer.py", line 763, in <module>
    curses.wrapper(mainloop, mycfg, mykeys)
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "./mlbviewer.py", line 185, in mainloop
    ( y , x ) = mywin.getsize()
  File "/home/matthew/mlb2013/MLBviewer/mlbListWin.py", line 25, in getsize
    ( y , x ) = os.popen('stty size', 'r').read().split()
IOError: [Errno 4] Interrupted system call
matthew@wheezy:~/mlb2013$
Normal wiggling doesn't do it. I have to give that corner a good shake to get that to happen. I don't think there's much I can do for that one. Anyway, if 0.5 second fixes your normal use, I don't want to spend anymore time on this.

EDIT: Removed the babbling and put it into the code.

Last edited by daftcat; 04-30-2013 at 12:45 AM.
 
Old 04-30-2013, 12:58 AM   #4017
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
SVN revision 458: aligned the cursors, added a config option for resizing

Implemented the cursor alignment code I talked about earlier. Now listings to scoreboard, scoreboard to listings, line score to scoreboard, etc should all retain cursor position.

Also removed the PgUp() trick on resize so you can resize the scoreboard and retain your cursor position. The nifty trick here is to start with a default 24x80 screen and highlight the last game in the listings. Switch to scoreboard and you should see that you are automatically scrolled to the next page. Now pull the bottom corner until all scores are on one page.

Added a config option called wiggle_timer. Since your machine may be faster or slower than mine, increase or decrease the wiggle_timer (takes float values so you can tune it as aggressively as you want) to match your system. Default is 0.5 but I may actually change this to 1.0 since my default home laptop seems happier with 1.0 than 0.5. Now my work virtual machine is quite a bit faster because it can handle 0.5 with all but the most aggressive corner wiggling. I'll test it on a few more laptops I have and see what values work best.

(Side note: my cable provider has been awful lately so it's exposing a lot of URLError crashes. I have a good idea of the next set of bugs to tackle. )
 
Old 04-30-2013, 04:16 AM   #4018
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
Crash is here:

Code:
Traceback (most recent call last):
  File "./mlbviewer.py", line 763, in <module>
    curses.wrapper(mainloop, mycfg, mykeys)
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
    return func(stdscr, *args, **kwds)
  File "./mlbviewer.py", line 185, in mainloop
    ( y , x ) = mywin.getsize()
  File "/home/matthew/mlb2013/MLBviewer/mlbListWin.py", line 25, in getsize
    ( y , x ) = os.popen('stty size', 'r').read().split()
IOError: [Errno 4] Interrupted system call
matthew@wheezy:~/mlb2013$
Normal wiggling doesn't do it. I have to give that corner a good shake to get that to happen. I don't think there's much I can do for that one. Anyway, if 0.5 second fixes your normal use, I don't want to spend anymore time on this.
I cannot reproduce this but if the signal causing the interrupt is SIGWINCH then moving:

( y , x ) = mywin.getsize()

up a line, so that it is above

signal.signal(signal.SIGWINCH, donothing)

will deal with it. When the signal handler is set to SIG_IGN, SIGWINCH will be ignored and discarded and blocking system functions will not be made to return with EINTR (including select(), which is what enables the interrupt throttling to work). When the signal handler is set to donothing(), donothing() doesn't execute anything, but blocking system functions will return with EINTR.
 
Old 04-30-2013, 05:39 AM   #4019
daftcat
mlbviewer Maintainer
 
Registered: Apr 2008
Posts: 1,748

Rep: Reputation: 76
Quote:
Originally Posted by chrisVV View Post
I cannot reproduce this but if the signal causing the interrupt is SIGWINCH then moving:

( y , x ) = mywin.getsize()

up a line, so that it is above

signal.signal(signal.SIGWINCH, donothing)

will deal with it. When the signal handler is set to SIG_IGN, SIGWINCH will be ignored and discarded and blocking system functions will not be made to return with EINTR (including select(), which is what enables the interrupt throttling to work). When the signal handler is set to donothing(), donothing() doesn't execute anything, but blocking system functions will return with EINTR.

That appears to have fixed it. Making this change and leaving wiggle_timer default of 0.5, I can no longer reproduce it on main home laptop. Checked in the change and will try again on work VM tomorrow (later today.)
 
Old 04-30-2013, 07:09 AM   #4020
chrisVV
Member
 
Registered: Aug 2010
Posts: 109

Rep: Reputation: 1
Quote:
Originally Posted by daftcat View Post
That appears to have fixed it. Making this change and leaving wiggle_timer default of 0.5, I can no longer reproduce it on main home laptop. Checked in the change and will try again on work VM tomorrow (later today.)
That's great. As an experiment I have caused all SIGWINCH interrupts in mlbviewer.py to be discarded everywhere except in select(): in other words, the interrupt handler is set as donothing() just before entering select, and then set to SIG_IGN as soon as it comes out (either when entering the exception handler's else block or before calling getch() where select has unblocked on keyboard input). Without the interrupt throttling, the program still misbehaves under a SIGWINCH storm. This seems to me to show pretty definitely that the problem is with the way python wraps select when receiving interrupt storms.

I don't suggest you reconfigure the code in this way in the release version of mlbviewer.py, because an ambidextrous user who both pressed a key and resized the window at the same time could lose the window redraw if the race went against her.

So I think the solution now adopted is probably the best that can be achieved, unless something else occurs to me.
 
  


Reply

Tags
help, install, installation, instructions, seek, vlc, windows


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
mlb.com gameday audio stream statmobile Linux - Newbie 6 05-06-2008 10:16 PM
link dies intermittently-seemingly at random- between win<->linux not linux<->linux?? takahaya Linux - Networking 10 03-09-2007 10:37 PM
triple boot linux/linux/linux No Windows involved toastermaker Linux - Newbie 12 03-02-2006 10:40 PM
Redhat (rhel v2.1) bootup problem with linux (linux vs linux-up) namgor Linux - Software 2 06-24-2004 02:49 PM


All times are GMT -5. The time now is 04:05 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration