| 18 | | when a resize is sent before mc is completely up, it doesn't get the geometry right, either - and yes, this happens about every time an xterm -e mc is restored by session management on my system. so the signal handler should be set up before the initial geometry is queried. |
| | 18 | when a resize is sent before mc is completely up, it doesn't get |
| | 19 | the geometry right, either - and yes, this happens about every time |
| | 20 | an xterm -e mc is restored by session management on my system. so |
| | 21 | the signal handler should be set up before the initial geometry is |
| | 22 | queried. |
| 40 | | Please commit it if it seems to be okay for you (I've been using mc 4.6.1 with this patch for a month, and found no side effects, while it makes mc much better when resizing the terminal). But please don't yet close this bugreport to remind us that a proper fix is still needed. This patch only makes it much better, but still there's a small chance for the bug to appear. Until we have a proper fix, it's good to apply a temporary hack to heavily decrease the chance for the bug. |
| | 48 | Please commit it if it seems to be okay for you (I've been using mc |
| | 49 | 4.6.1 with this patch for a month, and found no side effects, while |
| | 50 | it makes mc much better when resizing the terminal). But please |
| | 51 | don't yet close this bugreport to remind us that a proper fix is |
| | 52 | still needed. This patch only makes it much better, but still |
| | 53 | there's a small chance for the bug to appear. Until we have |
| | 54 | a proper fix, it's good to apply a temporary hack to heavily |
| | 55 | decrease the chance for the bug. |
| 55 | | Oh, I just found the pselect() call which is supposed to solve this problem. However, its manpage says the Linux kernel supports this only since 2.6.16 which is a quite new piece. It says that glibc had an emulation which is vulnerable to the race condition I just mentioned and pselect was just introduced for. |
| 56 | | The manpage also mentions and recommends the self-pipe trick which is more portable. |
| | 71 | Oh, I just found the pselect() call which is supposed to solve this |
| | 72 | problem. However, its manpage says the Linux kernel supports this |
| | 73 | only since 2.6.16 which is a quite new piece. It says that glibc |
| | 74 | had an emulation which is vulnerable to the race condition I just |
| | 75 | mentioned and pselect was just introduced for. |
| | 76 | The manpage also mentions and recommends the self-pipe trick which |
| | 77 | is more portable. |
| 72 | | Though this modification seems to solve my bug, another bug appeared. Press F5 on ".." so an error dialog box appears. Resize the window now. mc enters an infinite loop consuming 100% CPU time and not reacting on any keypress. I don't yet know how to fix this new bug. Swapping the new statement and the enable_interrupt_key() call right before it doesn't help either. |
| | 104 | Though this modification seems to solve my bug, another bug |
| | 105 | appeared. Press F5 on ".." so an error dialog box appears. Resize |
| | 106 | the window now. mc enters an infinite loop consuming 100% CPU time |
| | 107 | and not reacting on any keypress. I don't yet know how to fix this |
| | 108 | new bug. Swapping the new statement and the enable_interrupt_key() |
| | 109 | call right before it doesn't help either. |
| 74 | | On the other hand, even if we didn't have any side effects, my patch still doesn't fix my original problem, only decreases the possibility for this to occur. Still there is a chance that SIGWINCH arrives right after checking for winch_flag but before entering the select() call. |
| | 111 | On the other hand, even if we didn't have any side effects, my |
| | 112 | patch still doesn't fix my original problem, only decreases the |
| | 113 | possibility for this to occur. Still there is a chance that |
| | 114 | SIGWINCH arrives right after checking for winch_flag but before |
| | 115 | entering the select() call. |
| 76 | | I'm just curious how to solve this problem 100% perfectly, without any race condition, without the slightest possibility to misbehave. Now I'm interested in the theory first, not in the implementation details in mc. Let's suppose a single application that only wants to do two things: process data arriving from several file descriptors, and always correctly display the terminal size from its main loop (i.e. not from a signal handler, since doing complex things from a signal handler is just plain wrong). My only idea is the following: create a pipe, the sigwinch handler writes a byte into it, and the select() call checks for its reading end in addition to the other file descriptors it is interested in. This way the select() call immediately exits if there's an unprocessed sigwinch event, no matter if it occured before or during this select call. And of course we have to set the close-on-exec flag on these fd's so that subprocesses don't inherit them. |
| | 117 | I'm just curious how to solve this problem 100% perfectly, without |
| | 118 | any race condition, without the slightest possibility to misbehave. |
| | 119 | Now I'm interested in the theory first, not in the implementation |
| | 120 | details in mc. Let's suppose a single application that only wants |
| | 121 | to do two things: process data arriving from several file |
| | 122 | descriptors, and always correctly display the terminal size from |
| | 123 | its main loop (i.e. not from a signal handler, since doing complex |
| | 124 | things from a signal handler is just plain wrong). My only idea is |
| | 125 | the following: create a pipe, the sigwinch handler writes a byte |
| | 126 | into it, and the select() call checks for its reading end in |
| | 127 | addition to the other file descriptors it is interested in. This |
| | 128 | way the select() call immediately exits if there's an unprocessed |
| | 129 | sigwinch event, no matter if it occured before or during this |
| | 130 | select call. And of course we have to set the close-on-exec flag on |
| | 131 | these fd's so that subprocesses don't inherit them. |
| 80 | | Modern desktop environments and window managers usually resize the windows in an opaque way: plenty of resize events are sent to the application while the edge of the window is being dragged. This gives users a much better feedback than the ancient method (only showing where the edges of the window will be, and resizing when the mouse button is released), though it definitely requires much more cpu resources. |
| | 135 | Modern desktop environments and window managers usually resize the |
| | 136 | windows in an opaque way: plenty of resize events are sent to the |
| | 137 | application while the edge of the window is being dragged. This |
| | 138 | gives users a much better feedback than the ancient method (only |
| | 139 | showing where the edges of the window will be, and resizing when |
| | 140 | the mouse button is released), though it definitely requires much |
| | 141 | more cpu resources. |
| 82 | | Unfortunately mc is unable to properly handle when the terminal is resized opaquely. It receives tons of resize events (sigwinch), most likely ignores the new ones while processing an older one. Quite often when I finish resizing my window, mc draws its panels with a different size. Hence if I enlarge my terminal, I might get black columns/rows on its right/bottom part. If I shrink the window, the whole screen can be garbled. |
| | 143 | Unfortunately mc is unable to properly handle when the terminal is |
| | 144 | resized opaquely. It receives tons of resize events (sigwinch), |
| | 145 | most likely ignores the new ones while processing an older one. |
| | 146 | Quite often when I finish resizing my window, mc draws its panels |
| | 147 | with a different size. Hence if I enlarge my terminal, I might get |
| | 148 | black columns/rows on its right/bottom part. If I shrink the |
| | 149 | window, the whole screen can be garbled. |
