Re: [Gimp-developer] Script-fu-server and queuing

2004-07-07 Thread pcg
  Because the Gimp was not originally designed as a server, it does
  not follow some conventions that are necessary for such a mode. This
  includes the issue of managing shared resources among different
  threads of execution. A few of the resources that are not
  'thread-safe' include the current foreground/background color and
  brush shape.

Your can work around this problem by using Gimp::lock until it is
solved.

-- 
The choice of a  |
  -==- _GNU_ |
  ==-- _   generation Marc Lehmann +--
  ---==---(_)__  __   __  [EMAIL PROTECTED] |e|
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/   --+
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE|
   |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Script-fu-server and queuing

2004-07-05 Thread Oscar Picasso
Hi,

I use the script-fu-server and came across this remark at
http://people.westminstercollege.edu/students/d-b1649/linux/gimp_server.html

quote

Adding a Queue

Because the Gimp was not originally designed as a server, it does not follow
some conventions that are necessary for such a mode. This includes the issue of
managing shared resources among different threads of execution. A few of the
resources that are not 'thread-safe' include the current foreground/background
color and brush shape.

An example of the severity of this problem is if you are running two Perl
scripts at once on the same Gimp server. Let's say that the first script needs
to write some white text on a black background, and the second one needs to
write black text on a white background. Because the two are running at the same
time, the following sequence of events may occur:

   1. #1 sets the foreground color to white.
   2. #2 sets the foreground color to black.
   3. #1 writes some text to its black image, using the current foreground
color (which is now black.)
   4. #2 writes some text to its white image, using the current foreground
color (still black.) 

Obviously, script #1 ends up with an image that has the incorrect color of
text. The solution to this problem is to only allow the Gimp server to run one
script at a time. This is easier said than done, especially if you have
multiple scripts that run every few minutes. What you need to do is create a
queue system that maintains a list of scripts that need to be run and have a
separate program feed them into the Gimp, one by one. When a script wants to
run, it is submitted to the queue and waits for its turn. This kind of system
is almost identical to print queues, where multiple computers share one
printer.

/quote

On the other hand I took a look at the gimp sources and it seems there is some
kind of queuing mechanism build inside gimp.

I have also read the post
http://marc.theaimsgroup.com/?l=gimp-developerm=103142913407902w=2; about
queuing (for perl-fu, but I guess it's the same for script-fu)

From this post it seems that I can safely sent multiple concurrent requests to
the script-fu-server (apart the problem of memory consumption raised by the
initial poster of that thread).

What is the reality in this regard? Do I have to build my own queue or is it
handled by gimp.

I use v 1.2.3 but plan to upgrade to gimp 2.0. Is there a difference in that
respect between the two versions?

Thanks.



__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer