|Do you know where your variables are?|
I've had enough trying to figure out this bug and am ready to throw in the towel. As a last resort, I thought I'd ask here.
At this url (bundle.tar, 39K) is a cut-down version of the problem. Too much code to post, I'll give an walkthrough on creating the bug momentarily.
The problem is this: I've got multiple incoming sockets (IO::Socket::INET) that I'm managing I/O using select (IO::Select), when I have the listening program call Win32::Process::Create all of the *already established* sockets stop working. They don't report an error, it's just that select() on them stops working. It doesn't seem to matter what the program Win32::Process:Create calls actually does (the .exe included is a "Hello, world") it always causes this.
From what I've read, the third flag to W:P:C is supposed to control file descriptor inheritance by children, but I can't get it to work one way or the other and it may not even be the problem. If this were Unix, it'd feel like a child-closing-parent's-descriptors problem but I'm not entirely sure how Win32 is handling all of this.
So to re-create the bug, do this:
If you start multiple logstuff.pl instances, this doesn't happen. They can connect, disconnect, etc... without problem.
And once testcase.pl has (buggily) dropped all of the other incoming sockets, re-establishing new connections work fine. The prior ones are still ignored however.
If anyone knows the reason for this nonsense between select()/W:P:C I'd love to know the answer. I've searched the newsgroups and documentation and I'm resonably sure there's not an obvious answer. And I don't *think* I've got a bug in my code because I've marked everywhere I'm opening/closing/reading/writing sockets and I'm sure I haven't accidentally killed something.
Thank you for your time!
PS: Keep your style nits to yourself, remember this is a stripped down/test case version of something much larger.