GNOME Bugzilla – Bug 50649
Cannot run scripts synchronously
Last modified: 2004-12-22 21:47:04 UTC
As reported by Tim Lambert on the gimp-developer mailing list, and as discussed several times in the past, it is currently not possible to reliably call Script-Fu from another plug-in (written in C or Perl). Calling gimp_run_procedure2 returns immediately without waiting for the script to finish. As a result, the calling routine will start processing the image before the script has finished modifying it, and the results will be unpredictable. Even inserting some arbitrary sleep() calls after gimp_run_procedure2 will not work because it does not ensure that the script has enough time to process the image (and besides, this is an ugly kludge). It is also not possible to get the return value of the script, so the caller cannot know if the script has failed. It would be much better if the call to Script-Fu would block until the script has finished processing the image (or exited with an error) so that the exit status can be collected, and we could be sure that the image would not be corrupted by two processes working on it at the same time. This bug affects all versions of the GIMP (1.0.x, 1.2.x and current CVS).
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
I have to mark this as FIXED and not CLOSED, because the bug is fixed in CVS but version 1.2.3 has not been released yet so this bug cannot be CLOSED yet. I will close it as soon as 1.2.3 is officially released.
Wooops! Ignore the previous comment. This should have gone to bug #61525 instead. This bug is (unfortunately) still open.
Probably the best way to handle this is to make script-fu work like perl-fu, etc, as an interpreter that is loaded as needed instead of an extension that is always running. Now that init for plug-ins is (finally) implemented, this is possible.
Yes, running a new instance of the Script-Fu interpreter for every script would be one way to solve the problem, but at the cost of some performance degradation. Anyway, maybe this solution is easier to implement than a more complex locking mechanism with a pre-spawned process.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
The problem is that return values for temporary procedures were disabled long time ago without a good reason and without mentioning this in ChangeLog. While cleaning up the plug-in handling code i added the needed code back (inside #ifdef ENABLE_TEMP_RETURN). It's supposed to work and would block the caller until the procedure is finishes, just as with ordinary procedures. Currently, there are 3 places using temp procs: - The help browser - The PDB brush, pattern etc. selectors - Script-Fu Both the helpbrowser and the PDB dialogs could definitely handle this, and for script-fu it's highly probable that it will work too. We definitely cannot change this in the 2.x line, so i suggest enabling it now.
Go ahead and enable it.
Fixed in CVS: 2004-01-20 Michael Natterer <mitch@gimp.org> * app/plug-in/plug-in.[ch]: changed member "ProcRec *current_temp_proc" to "GList *temp_proc_recs", a stack of temporary procedures, just as the "temp_main_loops" member is supposed to be the stack of main loops for waiting for the temp_procs' return values. * app/plug-in/plug-in-run.c (plug_in_temp_run): changed accordingly. * app/plug-in/plug-in-message.c * app/plug-in/plug-in-run.c * libgimp/gimp.c: added #define ENABLE_TEMP_RETURN 1. Enables return values for temporary procedures. On the libgimp side, this just enables the code which returns the values, on the app side it enables per-plug-in stacks of proc_recs and main_loops and a message handler for the GP_TEMP_PROC_RETURN message. A temp_proc's caller now blocks until the proc is finished. Fixes bug #50649. Left the #ifdefs there so it can be easily disabled if things break. Please play with Script-Fu and test this.