Re: EPIPE
Raphael Quinet wrote: On Thu, 11 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: 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). Yeah, my confusing sentence above :) wanted to say: The # of SIGCHLD arriving doesn't have to correspond with the # of zombies we have to clean up. Of course just catching SIGCHLD doesn't touch the zombies at all. 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. Hm. I don't think that this is really a problem. The scenario above is, as you say unlikely but will definitely happen. But _if_ it happens we just have a stale zombie hanging around which should be cleaned up the next time the handler is called. 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". Wow, this is a bit more than what I was thinking about. I think this would be really useful. Still willing to hack it if comeone kicks you ?-) Ok, kick, kick, kick... 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. Yep, this sounds more useful than the current state (which just unblocks the signals in the handler if the trace is called and causes the loop if another signal arrives during and probably because of the trace). On Fri, 12 May 2000, Michael Natterer [EMAIL PROTECTED] wrote: [...] So ignoring SIGPIPE in the
List rules (Re: Negligencias medicas)
Hmmm... Sounds like spam to me. Cos it is. I though that only suscribed guys could post. If anybody can post, it should be fixed now. I think that is most of readers would like. The main problem is that the address seems to be a valid one (not random numbers or other garbage), so maybe he is suscribed. GSR
Re: Negligencias medicas
On Sat, May 13, 2000 at 09:21:59AM +0200, Pedro Arbiol Camps wrote: Todo lo que necesita saber para concienciarse de la Sanidad y sus carencias. No dude en aportar sus conocimientos, comentarios, dudas o experiencias a NEGLIGENCIAS.COM - EL BUSCADOR Could you please repeat that in English? Babelfish gives me: Everything what needs to know for concienciar of the Health and its deficiencies. It does not doubt in contributing its knowledge, commentaries, doubts or experiences to NEGLIGENCIAS.COM - the FINDER Hmmm... Sounds like spam to me. /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: List rules (Re: Negligencias medicas)
Guillermo S. Romero / Familia Romero wrote: Cos it is. I though that only suscribed guys could post. If anybody can post, it should be fixed now. I think that is most of readers would like. I like the idea of semi-moderated (non subscribers are moderated) lists but I don't have time to volunteer, so if no-one else likes that idea or XCF can't provide it, put me down for "subscribers only" too. Nick.
Translation Status Report
Hi, while the signal crew is trying to bring the pieces together again, GIMP is getting closer to its 1.2 release. Since we'd like to ship with a set of well supported languages, it's time again for a translation status report. There's still lots of work pending here. Please help the translators to finish their task... For a more colorful version of this status report, check out http://sven.gimp.org/1.1/i18n.html # Translation Status Report for gimp # generated Sat May 13 13:09:50 CEST 2000 # gimp.pot (1358 messages) ca 935 translated, 328 fuzzy, 95 untranslated. cs1358 translated. da1334 translated, 20 fuzzy,4 untranslated. de1358 translated. en_GB 92 translated, 15 fuzzy, 1251 untranslated. es1232 translated, 79 fuzzy, 47 untranslated. fi1290 translated, 20 fuzzy, 48 untranslated. fr1311 translated, 37 fuzzy, 10 untranslated. hu 346 translated, 602 fuzzy, 410 untranslated. it1313 translated, 36 fuzzy,9 untranslated. ja1333 translated, 20 fuzzy,5 untranslated. ko1071 translated, 218 fuzzy, 69 untranslated. nl 788 translated, 31 fuzzy, 539 untranslated. no1357 translated,1 untranslated. pl1040 translated, 28 fuzzy, 290 untranslated. ru1323 translated, 20 fuzzy, 15 untranslated. sk1108 translated, 179 fuzzy, 71 untranslated. sv1358 translated. uk1327 translated, 20 fuzzy, 11 untranslated. gimp-libgimp.pot (48 messages) ca 1 translated,1 fuzzy, 47 untranslated. cs 48 translated. da 48 translated. de 48 translated. en_GB8 translated, 40 untranslated. es 48 translated. fi 47 translated,1 untranslated. fr 48 translated. hu 3 translated, 25 fuzzy, 20 untranslated. it 48 translated. ja 48 translated. ko 24 translated, 13 fuzzy, 11 untranslated. nl 48 translated. no 48 translated. pl 48 translated,1 fuzzy. ru 48 translated. sk 22 translated, 15 fuzzy, 11 untranslated. sv 24 translated, 15 fuzzy,9 untranslated. uk 48 translated. gimp-std-plugins.pot (2775 messages) ca 1 translated,1 fuzzy, 2774 untranslated. cs2775 translated. da1499 translated, 1261 fuzzy, 15 untranslated. de2767 translated,8 untranslated. en_GB 142 translated, 64 fuzzy, 2569 untranslated. es 179 translated, 89 fuzzy, 2507 untranslated. fi 184 translated,6 fuzzy, 2585 untranslated. fr2659 translated, 88 fuzzy, 28 untranslated. hu 1 translated,1 fuzzy, 2774 untranslated. it1413 translated, 700 fuzzy, 662 untranslated. ja2246 translated, 80 fuzzy, 449 untranslated. ko 748 translated, 1254 fuzzy, 773 untranslated. nl 1 translated,1 fuzzy, 2774 untranslated. no1174 translated, 607 fuzzy, 994 untranslated. pl 296 translated, 1245 fuzzy, 1234 untranslated. ru2658 translated, 27 fuzzy, 90 untranslated. sk 1 translated,1 fuzzy, 2774 untranslated. sv 59 translated, 244 fuzzy, 2472 untranslated. uk 754 translated, 16 fuzzy, 2005 untranslated. gimp-perl.pot (298 messages) cs 298 translated. da 138 translated, 158 fuzzy,2 untranslated. de 293 translated,3 fuzzy,2 untranslated. fr 64 translated, 19 fuzzy, 215 untranslated. it 291 translated,6 fuzzy,1 untranslated. ja 49 translated,4 fuzzy, 245 untranslated. no 295 translated,3 fuzzy. ru 176 translated,4 fuzzy, 118 untranslated. uk 163 translated,4 fuzzy, 131 untranslated. gimp-script-fu.pot (423 messages) ca 1 translated,1 fuzzy, 422 untranslated. cs 423 translated. da 419 translated,2 fuzzy,2 untranslated. de 423 translated. en_GB1 translated,1 fuzzy, 422 untranslated. es 14 translated, 145 fuzzy, 264 untranslated. fi 3 translated,1 fuzzy, 420 untranslated. fr 35 translated, 89 fuzzy, 299 untranslated. hu 1 translated, 422 untranslated. it 134 translated,6 fuzzy, 283 untranslated. ja 134 translated, 26 fuzzy, 263 untranslated. ko 21 translated, 100 fuzzy, 303 untranslated. nl 1 translated, 422 untranslated. no 128 translated, 134 fuzzy, 161 untranslated. pl 13 translated, 102 fuzzy, 309 untranslated. ru 411 translated,2 fuzzy, 10 untranslated. sk 1 translated, 422 untranslated. sv 3 translated,8 fuzzy, 413 untranslated. uk 81 translated, 66 fuzzy, 276 untranslated.
GIMP Developers Conference
Hi, We are proud to be able to announce the first official GIMP Developers Conference which will take place June 2nd - 4th 2000 in Berlin. The goal of this conference is to bring together GIMP developers to chart the features of the next generation GIMP. There are lots of decisions to be made and we hope that this meeting will help us to design the framework for Gimp-2.0. The meeting will take place in the rooms of the CCC (Chaos Communication Club) in Berlin. While we can have those rooms for free, there is only limited space. Therefore, if you want to come to the conference, please email us at [EMAIL PROTECTED] so we have an idea about the number of people interested in joining us. Eventually we'll have to close the list at some point. More info will soon become available at http://www.gimp.org/gimpcon/ In the meantime you can peek at the preview of the conference homepage: http://sven.gimp.org/gimpcon/ Salut, Sven
