| [reply] |
Sorry my ignorance, but I don't know much about Windows:
Would "something" fit, for instance, a process which started our Perl process, and then delivered a Windows Message to this process, and Perl, not knowing what to do with this message, invokes the signal handler established for SIGHUP?
In our case, the parent process would be Console2 (a sourceforge application which hosts several DOS Console session in parallel), so this might be a possible culprit...
--
Ronald Fischer <ynnor@mm.st>
| [reply]
[d/l] |
Would "something" fit, for instance, a process [ Console2 ] which started our Perl process, and then delivered a Windows Message to this process, and Perl, not knowing what to do with this message, invokes the signal handler established for SIGHUP?
No. I downloaded the source for console2 and the string "SIGHUP" does not appear anywhere in it, so your log message does not come from that.
As I said, I don't believe there is any way for a perl process to ever invoke a SIGHUP handler. Which only leaves your perl script to be the source of that log message in response to some stimulus other than a sighup. (ie. user error)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
