Markus Roberts <[email protected]> writes: >> just a note: it's quite essential that SIGPIPE is set to SIG_DFL in the >> child process. luckily, execve(2) will reset to SIG_DFL unless it's set >> to SIG_IGN. a child with SIGPIPE set unexpectedly to SIG_IGN can easily >> get stuck in endless loops. the grandchild SHOULD die when it tries to >> write to the closed stdout. > > Agreed in principe; in practice this branch (which is not being > included as it fails in real world use) was intended to expose/explore > the behavior of certain ill behaved processes in an effort to > determine what they were doing and how best to work with them.
well, in practice SIG_IGN *will* cause any numbers of problems, even with well-behaved applications. >> I guess this will work, but it seems a bit hackish compared to just >> catching SIGCHLD. if done right, no polling (timeout) is needed. > > More than a bit hackish, it evolved into a large, brittle kludge. > Just catching SIGCHLD (which could be beautifully done) is, as > explained on the tickets, woefully inadequate. I read ticket #3013, and didn't find anything about that inadequacy. this isn't really a very unique problem to solve, a lot of applications have done this before, efficiently. (e.g., reading large blocks is guaranteed safe when reading from "slow" devices, this includes pipes and sockets. a "fast" device (ie. hard disk) will hang until the whole request is fulfilled, but you need a hardware error for that to happen.) >>> ENV['LANG'] = ENV['LC_ALL'] = ENV['LC_MESSAGES'] = ENV['LANGUAGE'] >>> = 'C' >>> Kernel.exec(*command) >> >> not part of your patch, but I couldn't resist commenting on this cargo >> cult code :-). setting ENV['LC_ALL'] is sufficient. 'LANGUAGE' is not >> POSIX, and not consulted when LC_MESSAGES (effectively) is 'C'. > > We got into this problem by cleaning up code that was "obviously" > unneeded and found to our dismay that there were environments were it > was not as superfluous as it appeared. You may be perfectly correct > but I'm not going to compound the error by making the same mistake > again, pulling out tested, working code at the eleventh hour just > because we all agree it probably isn't needed. that's the very definition of cargo cult :-) -- Kjetil T. Homme Redpill Linpro AS - Changing the game
-- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
