- timed_mutex -- but it acquires the lock - 4 Updates
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 10 08:06AM -0800 Okay I'm starting to think that a process might not be salvageable after any of its threads is killed or cancelled. So instead maybe I could program a mutex watchdog system something like as follows: (1) Periodically check that all the worker threads are still alive. (2) If one of the watchdog timers times out, do the following: (2.a) Take a photograph of the GUI window on the screen, i.e. take a screenshot of it and save it as a bitmap. (2.b) Save the values of all the widgets to a file (e.g. the text in text boxes, whether a tick box was ticked, the position of a slider). (3) Start a new process that does the following: (3.a) Displays the aforementioned bitmap on the screen over the real dialog (3.b) Kills the main program (3.c) Restarts the main program and loads the widget values from the file (3.d) Removes the fake bitmap off the screen The idea here is that the main program would be killed and restarted without so much as a flicker on the screen. |
| David Brown <david.brown@hesbynett.no>: Feb 10 05:30PM +0100 On 10/02/2023 17:06, Frederick Virchanza Gotham wrote: > Okay I'm starting to think that a process might not be salvageable > after any of its threads is killed or cancelled. Progress! > (3.d) Removes the fake bitmap off the screen > The idea here is that the main program would be killed and restarted > without so much as a flicker on the screen. You are over-thinking this all. Make a supervisor process that monitors the working process, and kills then restarts it if necessary. That's fine, and a commonly used strategy for high availability systems. Having a method of tracking the existing settings or configuration, then replicating them on restart is perhaps useful, but perhaps worse than useless. The process hung and was killed because of a software error - replicating the state could lead to exactly the same fault. (This effect can be a PITA with web browsers that crash due to problems with a web page, then try to restore the session on restart and crash again.) Faffing around with bitmaps and screenshots in order to avoid flicker is, however, utterly ridiculous. If flicker is annoying users, then find and fix the software bug that is causing the hang - don't waste effort on a complicating system to try to hide the problem. You'll just introduce even more bugs. |
| scott@slp53.sl.home (Scott Lurndal): Feb 10 05:02PM >Make a supervisor process that monitors the working process, and kills >then restarts it if necessary. That's fine, and a commonly used >strategy for high availability systems. Indeed. Such an approach is less viable for the interactive GUI program that Frederick is proposing, which may require that he rethink the application and perhaps disaggregate the worker parts of the application from the display management elements. |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 10 08:57PM +0200 10.02.2023 18:06 Frederick Virchanza Gotham kirjutas: > So instead maybe I could program a mutex watchdog system something > like as follows: > (1) Periodically check that all the worker threads are still alive. I'm not sure why you are fixated on thread deadlocks. Why don't you worry about NULL dereferences or other violations which will typically kill the process on spot? > a screenshot of it and save it as a bitmap. > (2.b) Save the values of all the widgets to a file (e.g. the text in > text boxes, whether a tick box was ticked, the position > of a slider). It would be much easier and more robust (and would also work in case of crash) to save settings in file or in registry as soon as they are changed. > (3.d) Removes the fake bitmap off the screen > The idea here is that the main program would be killed and restarted > without so much as a flicker on the screen. I'm just curious - what is the intended purpose? You don't really expect the user is so dumb that they will not notice when your buggy program freezes or misbehaves, but yet will somehow notice some flicker on the screen? |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment