Hmm, if any of perl's internal calls are ignoring it without a good reason (I guess a "panic: interpreter is broken" would be a good reason) then that's probably a bug that should be fixed; in any case, the underlying *STDERR still points to the standard Apache error log, so such messages won't be lost entirely. (And in fact that seems like the real benefit of the tie - if anything goes horribly wrong in the logging code, the fallback is as simple as untie *STDERR.)
In general, if anything is calling out to a separate process I'd expect it to be handling STDERR from that itself - exactly as Email::Valid is trying to do - so I don't think that's a problem either.
The issue as I see it is making sure I get out of the way of such child processes, so that they are actually able to handle STDERR themselves. And to do that, either I've got to know in advance that the child process will be created (as I now do for the MX check), or I have to get perl to tell me that it's about to happen (or has just happened).
Hugo
In reply to Re: Re: Catching fork() with tied STDERR
by hv
in thread Catching fork() with tied STDERR
by hv
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |