Hi, Oscar Picasso <oscgoogle@xxxxxxxxx> writes: > 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> I don't think a queue is the way to go here. In gimp-2.0 we have introduced the concept of a GimpContext that holds the foreground and background colors, current brush, pattern, gradient and all that. The solution is though to let each script/plug-in run in it's own context. We didn't do that yet because some scripts rely on the possibility to manipulate the user context. The best thing to solve this is probably to let scripts work in their own context by default and add an API to manipulate the user context. Sven
