[PERL SCRIPTS] get surface
Hi ! I'd like to get some surface from a picture through perl script let say some gimp_get_surface(x1,y1,x2,y2) which could output some matrix - PDL structure. Does such method has been implemented yet ? Regards, Fabian
Re: EPIPE
On Friday, 12 May 2000, Marc Lehmann wrote: [1: plugins should have the system default signal handers, not gimp ones] [2: main gimp app should have system default SIGPIPE handler] Point 1: I mainly agree with this. I can't think of a need to hook any signals. Did plugins used to give backtraces when they crashed? I think they did: if so, and people want to keep this functionality, then unfortunately plugins need to hook signals in a similar manner to the main gimp app. However, plugins definitely won't benefit from SIGCHLD handers or ignoring SIGPIPE. If a plugin tried to write to the gimp pipe and gets a SIGPIPE, it's because the main gimp app has died. The plugin should die as swiftly as possible, in this case. Point 2: The main gimp app should ignore SIGPIPE, so that an EPIPE can be generated in a controlled manner to be collected and acted upon by the plugin management routines in plug_in.c With all this vigorous discussion going on, I seem to be a little confused. Can someone (Mitch, Garry?) summarise what the current CVS signal handling situation is, and what changes (if any) are planned? Austin
Re: EPIPE
On Fri, 12 May 2000, Marc Lehmann wrote: On Thu, May 11, 2000 at 09:05:58PM +0200, Michael Natterer [EMAIL PROTECTED] wrote: The libgimp code could try to set the signal handler to SIG_DFL before executing the code of the plug-in. We don't need to do this, as (exec()'ed) children can't inherit handlers from their parent anyway. If you ignore signals (you said so) this is very well inherited by children (this is how programs like nohup work). However, this is not necessarily a problem, of course. It might just be unexpected by libgimp in the child, for example, or by plug-ins, and most probably it's not the intented action to ignore any signals by default (where the default action isn't ignore) in the plug-ins. Oops, you're right. Of course only signals which are connected to a handler are reset to their default disposition on exec() at.al. So ignoring SIGPIPE in the app causes it to be ignored in children, too. To avoid the need of resetting the signal we could just connect it to a dummy handler and let exec() do it's job of resetting it. I would really prefer leaving most of the signal handlers intact (or under program control). It would be nice if a plug-in could choose to call gimp_signal_safetynet (); If it wanted all it's signals to be clobbered. And gimp_main could change the signals it really requires. The problem is that now, a call to gimp_main (which doesn't return) changes signal handlers without leaving the caller the option of not (or the option of later re-setting them again, since "later" might be never) Hm, we install the signal stuff before the call to gimp_loop() which in turn calls the plugin's run() function after which the plugin is closed anyway. So why can't you just do the signal setting which have to be special in the run() procedure. There is nothing really happening in between (well, except the config message arriving but that shouldn't hurt). signal handlers installed by the Gimp should call the ones that were installed before. But then we have to support the systems that have Do you really think this is neccessary? I can imagine that gimp needs control over a few signals (although I cannot imagine which ones at the moment). The current situation, however, is, that gimp (or glib?) changes many signals in plug-ins (like SIGPIPE) without any visible benefit. Inherited settings are not the problem here (no handlers). Plugins connect fatal signals to the fatal handler (stacktrace), ignore SIGPIPE to get notified of a crashing gimp by the new gimp_plugin_io_error_handler() (because SIGPIPE didn't work) and they connect SIGCHLD to a handler which is identical to the one in the main app (to clean up zombies). I'd rather like to wait it the current code (which is not really different from the old one except that it uses sigaction()) works as expected. It's indeed the behaviour of the old code that's bugging me ;) But I get a bit nervous when the number of clobbered signals increases, rather then decreases. Only SIGCHLD and SIGPIPE disposition has changed in plugins. But I'm of course willing to change my mind if someone shows me where the problem is. (the problem may be that I still don't understand why you think you cannot change gimp_main()'s signal settings :) bye, --Mitch
Re: EPIPE
On Thu, 11 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: Raphael Quinet wrote: No, actually it is not safe on all operating systems: as I wrote elsewhere, you cannot always rely on SA_NODEFER. This means that in some cases, you could miss a SIGCHLD signal that occurs while you are still inside the handler but after the last test on waitpid(). If this happens, the main app will not see that one of the plug-ins has died (until another one dies and the handler collects the status for both). That's why it is safer to make the tests outside the signal handler. Otherwise, you could have a race condition on some systems (very seldom, but still...). We don't use SA_NODEFER any more. And AFAIK the delivery of SIGCHLD has nothing to do with cleaning up zombies. This is why we loop around waitpid() because POSIX explicitly says that signals arriving close together may be merged by the kernel. The delivery of SIGCHLD does not clean up the zombies: this is done by calling waitpid() or any wait*() function. But the call to waitpid() will be triggered by a SIGCHLD, and there is a potential race condition. I will try to explain this in a slightly different way: regardless of the setting of SA_NODEFER, you cannot ensure that you will get one SIGCHLD for every dead process. Some kernels merge the signals that arrive close together, and some of them mask the signal while the corresponding handler is being called (some systems will re-deliver the masked signal immediately after the handler returns, but this is not always the case). Now, consider the following scenario for a race condition: * The Gimp starts two plug-ins * plug-in 1 dies * SIGCHLD delivered, handler called * inside the signal handler: * - waitpid() returns the status of the first process * - waitpid() returns 0 and the while() loop ends * plug-in 2 dies (before the signal handler returns) * SIGCHLD cannot be delivered * - the signal handler returns * The Gimp continues and the status of second plug-in is never collected, so this creates a zombie. Although it is rather unlikely that a context switch happens in the signal handler just after the while() loop and before returning, it can and will happen. If you are sure that all kernels of the systems that Gimp supports will re-deliver the second SIGCHLD signal immediately after the signal handler returns, then there is no problem in the scenario described above: the handler will be called a second time and will collect the status of the second plug-in. But I do not think so; that's why I suggested to call waitpid() outside the signal handler, because then you avoid the race condition. Yes... I wrote a few months ago that I would change that and implement some kind of --enable-stack-trace option, but I never took the time to do it. Now it's there :) We just have to convert the remaining g_print() to write() and the handler will be totally safe if enable_stack_trace == FALSE. Hmmm... I don't know how you have implemented it (I cannot look at the CVS code), but I was thinking of having more options for --enable-stack-trace, both for the configure option and for the command-line option: - "never": disable the stack trace and use the default signal handlers - "query": ask the user, as we are doing now. - "always": always call the debugger without asking any question (useful if stdin does not work, but stdout is still OK) - "wait": always wait 30 seconds, without asking any question (this does not use stdin or stdout and gives some time to the user if she wants to attach a debugger to the process) If the code is compiled or run with the "never" option, then the signal handlers would never be installed. The configure option would set the default value for this flag, but it would always be possible to override it with the command-line option without recompiling. The default for the code in CVS and for the unstable tarballs should be "query", and the default for the stable releases could be "never" or "wait". We should probably re-add the reentrancy guards in the fatal handlers and just do a brute force exit() if it's called recursively (which can only happen during the stack trace because that's the only case where the signals are unblocked in the handler). Another option would be to set the signals to SIG_DFL as soon as the fatal handler is called. Since the default behavior for these signals is to kill the program, this would prevent the endless loop without requiring a special flag. On Fri, 12 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: [...] So ignoring SIGPIPE in the app causes it to be ignored in children, too. To avoid the need of resetting the signal we could just connect it to a dummy handler and let exec() do it's job of resetting it. Well, as I wrote above and in a previous mail, there is a convenient SIG_DFL that exits for that purpose, so you do not have to install a dummy
New version of gimp_tips.txt
I uploaded the gimp_tips patch to ftp.gimp.org a few days ago, but apparently it has not been moved out of the incoming directory yet, and not comitted to CVS. Maybe some of you would like to have a look at the updated file, so I have put it temporarily on this page: http://www.gamers.org/~quinet/gimp/gimp_tips.txt This is only a temporary location and I will delete it a few days after the next release. But in the meantime, you can have a look at it and maybe send more suggestions... -Raphael
Re: [PERL SCRIPTS] get surface
On Fri, May 12, 2000 at 08:39:31AM +0200, [EMAIL PROTECTED] wrote: script let say some gimp_get_surface(x1,y1,x2,y2) which could output some matrix - PDL structure. Does such method has been implemented yet ? It works just like in C. Check the scripts plug-ins/perl/examples/map_to_gradient and plug-ins/perl/examples/border_average for two different ways to access pixel data. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
