On Mon, Sep 11, 2000 at 10:32:42AM +0100, Austin Donnelly <austin@xxxxxxxx> wrote:
> From your evidence with sleep() it does sound like the call to the
> plugin is not blocking until the plugin returns.
Yes, but this is impossible to _program_ using the current API. The only
way to return to the caller is by returning form the plug-in.
> I'm not sure whether the call goes via the main application, or if the call goes directly.
Always through the main gimp process.
> Again, this is where per-image locks would help sort these kinds of
> problems out.
I am afraid per-image-locks are an orthogonal concept: Either
per-image-locks are per-function-call (which leads into the next
alternative) or the called plug-in has to inherit all locks somehow, which
would mean locks wouldn't help.
> a) make calls to plugins from other plugins block properly, as you,
> Marc and presumably others expect.
This is the current state: remember that it is only script-fu that makes
problems, and script-fu could *never* be called properly form other
plug-ins, so I guess the problem really is script-fu. Especially since all
other plug-ins work fine (some perl-plug-ins even call other perl plug-ins
through the pdb with no problems). If this were a common issue much more
things would break.
> when it should be used. But, it might be easier to do than a). I
> don't know, I haven't looked at the code.
Since a) is currently implemented, I at the moment think that some of the
original diagnosis was wrong, i.e. the code just happened to run by chance
due to the sleep, and the real bug was to re-use a layer that does not
really exist as previous anymore. The only other thing I could think of is
that some core (in-gimp) pdb call returned before the appropriate action
was carried out, but this is unlikely.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
