Open Earnestly opened 9 years ago
Blegh, nevermind. Now there's a huge spike of cpu usage about 1 minute in and setting different timeouts isn't a solution. At this point I don't know what could be the issue or the solution.
The high cpu usage impacts the X server especially so it's likely related to xlib/xcb internals that I have no idea about.
Hopefully you will have better insight about this situation than I.
Hi. I don't know why I never got any notification about this (I checked my mailbox, I assume one of my old filters removed it). I'm sorry about that. I saw this PR because I got a notification about another PR that I just merged. I haven't been running hhpc myself for a while (currently on a Chromebook SSH'ing into the boxen I manage). But I'd be happy to review this if you're still interested in this. I know it's been a very long time. Let me know, and sorry again.
Ah no worries about it, I've forgotten all about it as well
This patch attempts to fix two corner cases which can result in hhpc becoming deadlocked, https://github.com/aktau/hhpc/issues/9.
The first checks for the case where nanosleep() is interrupted which would set working to 0 and as hhpc never recovers from this case, the program will lockup indefinitely. Instead we resume where we left of if encountering EINTR.
The second fix is a bit of a hack; on rare occasions the select() call in waitForMotion can seemingly block and practically never recover (I didn't wait for more than one hour).
Instead I added a timeout to the select call, based on the gIdleTimeout value if it is greater than 1, otherwise it uses a 3 second delay. (This implies you can set a timeout of 2 seconds and have a 2 second timeout.)
This doesn't really solve the issue of why select is getting stuck but does allow hhpc to recover and prevent it from holding the mouse hostage.