imm wrote: > On 5 Mar 2008, at 18:47, Alvin wrote: > >> 1. Using Fl::grab() on a hidden window. At the start of the >> calculation, "grab" the window which, if I read the docs right, would >> prevent the user events. Upon completion, I would ungrab the window. > > How well grab works depends heavily on what OS, Xserver, WM, etc., > you have, so probably is not a robust solution... > >> 2. Using some kind of semaphore/lock method. Basically, I set a >> "busygoaway" >> flag to true. Then, in the slider's callback, if "busygoaway" is >> set, do >> not allow the slider to be changed. This may work, but what if the >> input >> file is closed by the user during the calculation. I guess I would >> need to >> check the "busygoaway" flag in every possible operation?? > > Sounds like it could work. > >> 3. ???? > > Dunno... what's the actual nature of the segfault? Maybe there's > something there that could be "fixed" so that the user could interact > (and be ignored?) without triggering a fault?
The segfault occurs because the input is either modified (File->Open, File->Close, etc.) or the entry function that starts the calculation is called again (slider changed). It's like the calculation is being manipulated in mid-execution. The actual segfault is a nice side effect. Worse case scenario is that the calculation continues but the result would be undefined (half missing, corrupted, etc.). So, it's a fundamental crash. Here's an example. Say you are saving a PNG (2302x1728) using best compression. That's going to take some time. While libpng is creating the PNG you hook in a Fl_Progress to display the status via libpng's callback mechanism. Now, while the image is saving (save 33% done) you close the input image (File->Close) which releases the memory of the source image. libpng will most like blow a gasket or give you a garbage PNG since the memory is was reading has been invalidated. That's kind of what occurs in my situation. I think another solution might be to figure out if the calculation can be stopped prematurely and then restarted. The problem with this is that part of the work is done in another library that knows nothing of user interfaces and believes its operations are atomic. This is where I believe the Fl::check() is interfering. For the Fl::grab(). The program will be running on openSUSE 10.3 only. So, portability isn't really a factor for this version. I think I will try the Fl::grab() approach. If that doesn't work I think I will keep it simple and go back to my original Fl_Progress_Window which is modal. A modal window would certainly prevent this scenario from happening. -- Alvin _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
