On Sun, Sep 10, 2000 at 10:39:26PM -0500, "Michael J. Hammel" <mjhammel@xxxxxxxxxxxxxxxxx> wrote:
> > Not in the current architecture. The caller is blocked until the called
> > plug-in has finished.
>
> That would be the preferred design, but my tests don't seem to bear this
> out. Again, I could be misinterpreting the results, though I'm fairly
> certain I'm not.
You must, since if this were true we could expect a lot more breakage, but to
the contrary it's only script-fu. Also, the API for plug-ins looks like this:
function run_callback()
{
... parse agruments
... execute script
... create result values
return;
}
Only when the plug-in returns results values are passed back. There
is currently no way for a plug-in to both return from the call AND do
something.
> script_fu_old_photo($drawable, 0, 1, 1, 1, 0);
Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is
passed in. Using the drawable after that was a bug in your (original) code
(this is a very common bug).
# # $drawable no longer valid
> $drawable = gimp_image_get_active_layer($img);
# # $drawable valid again
> If I remove the sleep() call then Gimp crashes
The bug here is that Gimp crashes while it shouldn't, but this is more
a cosmetic problem (it's still easy to crash the gimp using illegal pdb
calls, unfortunately).
> only 1 second, various results occur. If I don't use the call to
> gimp_image_get_active_layer(), with or without the delay, then Gimp crashes.
The problem seems to be that old_photo calls flatten, and this might
change a lot of internal structures. the right fix would be to make
old-photo return the newly created layer/image/whatever, but AFAIK
script-fu is unable to return anything to the caller (scirpt-fu was never
designed to be called from the outside, obviously).
> tells me that the blocking you mention isn't happening. In fact, I can
> watch part of the drop shadow actually being performed on the image *before*
> any visible results from old_photo happen - all before Gimp crashes. Weird,
> but that's what I'm seeing.
I doubt that this has something to do with the plug-in API. Most probably
some pdb function only starts the rendering (AFAIK there was some
semi-recent change to push some long-running-ops into the background, so I
guess some locking there is missing).
> True. Still, my misuse of a valid drawable was unexpected for the Gimp. There
> may be some error checking that could be done to prevent the crash,
Well, it's not as if a the developers didn't put a lot of effort into
argument checking. It is definitely much more difficult to crash the gimp
now than half a year ago ;)
> this can't be addressed before 1.2 is released) to make a note that
> serializing of calls to plug-ins from plug-ins is not guaranteed.
This is highly unlikely. the current set of perl plug-ins call a lot of
other plug-ins (including pelr ones) without a problem. I am quite certain
it's either an uncommon operation or yet another script-fu-breakage, for
example, script-fu is the only plug-in that stays in memory all the time,
even if not used, and uses temporary pdb functions instead of normally
registered calls (that's why it's so slow on startup). This could be the
key...
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
