<p><a href="https://github.com/b4n" class="user-mention">@b4n</a><br>
<a href="https://github.com/kugel-" class="user-mention">@kugel-</a></p>
<p>The story so far:</p>
<p>Ubuntu 14.04 / glib 2.40 / Geany-1.30.1 - works.<br>
Ubuntu 16.04 / glib 2.48 / Geany-1.30.1 - hangs.<br>
Ubuntu 17.04 / glib 2.52 / Geany-1.30.1 - hangs.</p>
<p>I ran a "hanged" Geany for 1 hour, with some occasional traffic.<br>
It was extremely slow, of course, and never recovered by itself.</p>
<p>Then I left the time-sourced version idle for 1 hour on a "single" 3.0GHz virtual CPU.<br>
It wasted ~8.3 seconds.</p>
<p>Now, there is a chance that removing the timeout source and creating a new watch source will temporarily fix the input state. But replacing sources it not free either, and each<br>
time we switch from watch to timeout, we wait for 200 empty GIO_IN-s, which takes, say, 0.04 sec (YMMV). If we have 208 switches for an hour long debugging session - and each "Step" or automatic tooltip in Scope will likely generate a switch - the effect is zero.</p>
<p>Another thing I noted is that practically blocking the glib main loop has side effects. At one time, I activated File -> Open, then killed gdb, which freed the CPU, and the file<br>
open dialog was immediately displayed - but neither [Open] nor [Cancel] worked. So I'd rather avoid frequent empty G_IO_IN sequences.</p>
<p>Considering also the added complexity, I'm not going to write a switch-back-and-forth mechanism. This PR is a hack (gee), and I don't want to make it nastier than required.</p>
<p>TODO: test more glib versions: 2.53, 2.44, 2.??</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/pull/1461#issuecomment-315166220">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ1EZBse5sn7hRvaXq2v9DIfvzP2Yks5sNmS3gaJpZM4M3KqU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ9jDbafhf7fonVLzXiyX8DB_rkSIks5sNmS3gaJpZM4M3KqU.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/1461#issuecomment-315166220"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@zhekov in #1461: @b4n \r\n@kugel- \r\n\r\nThe story so far:\r\n\r\nUbuntu 14.04 / glib 2.40 / Geany-1.30.1 - works.\r\nUbuntu 16.04 / glib 2.48 / Geany-1.30.1 - hangs.\r\nUbuntu 17.04 / glib 2.52 / Geany-1.30.1 - hangs.\r\n\r\nI ran a \"hanged\" Geany for 1 hour, with some occasional traffic.\r\nIt was extremely slow, of course, and never recovered by itself.\r\n\r\nThen I left the time-sourced version idle for 1 hour on a \"single\" 3.0GHz virtual CPU.\r\nIt wasted ~8.3 seconds.\r\n\r\nNow, there is a chance that removing the timeout source and creating a new watch source will temporarily fix the input state. But replacing sources it not free either, and each\r\ntime we switch from watch to timeout, we wait for 200 empty GIO_IN-s, which takes, say, 0.04 sec (YMMV). If we have 208 switches for an hour long debugging session - and each \"Step\" or automatic tooltip in Scope will likely generate a switch - the effect is zero.\r\n\r\nAnother thing I noted is that practically blocking the glib main loop has side effects. At one time, I activated File -\u003e Open, then killed gdb, which freed the CPU, and the file\r\nopen dialog was immediately displayed - but neither [Open] nor [Cancel] worked. So I'd rather avoid frequent empty G_IO_IN sequences.\r\n\r\nConsidering also the added complexity, I'm not going to write a switch-back-and-forth mechanism. This PR is a hack (gee), and I don't want to make it nastier than required.\r\n\r\nTODO: test more glib versions: 2.53, 2.44, 2.??\r\n"}],"action":{"name":"View Pull Request","url":"https://github.com/geany/geany/pull/1461#issuecomment-315166220"}}}</script>