On Thu, Jan 19, 2012 at 2:01 PM, el jefe delito <eljefedelito at gmail.com> wrote: > I am talking out of my backside here, as a non-programmer, but... >> How can you handle a crash in a nice way? An application shouldn't >> crash, but when it crashes it's too late. > > How does an app crash and not bring down the whole OS? ?How does Adobe Flash > crash often but not bring down Chromium? ?How does the Desktop Capture crash > and not bring down KDEnlive? ?Is there a way to do something similar in other > parts of KDEnlive, and allow these parts to be restarted? >
These occur through process isolation. Web browsers like Chromium run each tab and plugins in separate processes from the browser shell. Kdenlive already spawns separate processes for screen capture, transcoding, and rendering thereby protecting the editing project. Kdenlive could potentially run the bulk of its editor in a separate process and leave only the window and perhaps a dialog upon crash - something like Firefox does as Brian mentioned. That would only add minor user experience sugar over simply using the desktop environment to restart kdenlive. Now, the more extreme approach that would require serious engineering is to run the majority of MLT in a separate process. To do this strictly from MLT to Kdenlive would get messy due to things like GUI toolkit and the way XVideo is being used today for better performance. We may be able to add around something around MLT that runs the main object graph in separate process and uses shared memory to transfer the audio and image to a parent process using the MLT output plugins. But that will also require the addition of a complete IPC layer over the MLT API so the Kdenlive logic can still manipulate the object model of the composition. And in the end, all that buys you is MLT isolation, and crashing bugs within Kdenlive code still leaves Kdenlive vulnerable. -- +-DRD-+
