Re: Preventing IO::Handles from closing on destruction

The only solution I have found involves maintaining a list of handles in the main thread and dropping them after the worker thread indicates it is done

I think this is exactly the way to go if you need to pass file descriptor numbers around for some reason. If you don't want $c to go out of scope, just keep it around for as long as needed.

Comment on Re: Preventing IO::Handles from closing on destruction Download Code

Replies are listed 'Best First'.
Re^2: Preventing IO::Handles from closing on destruction by exaethier (Initiate) on Nov 04, 2011 at 15:36 UTC
Fair enough. I tried implementing this and hit an unexpected problem. The close() call in worker thread does not actually close the socket. The connection does not actually close until the preserved file handle in the main thread goes out of scope. Unfortunately, this is after the next connection comes in, as the main thread is block in accept() ... no non blocking calls on w32 AFAIK. Any thoughts on how to force the duplicated socket to close?	[reply]
Re^3: Preventing IO::Handles from closing on destruction by Eliya (Vicar) on Nov 04, 2011 at 15:55 UTC
On Unix, I would try `POSIX::close($fileno)`, which operates directly on descriptor numbers (not handles). Not sure if that works on Windows, though, or what the equivalent would be...	[reply] [d/l]
Re^4: Preventing IO::Handles from closing on destruction by exaethier (Initiate) on Nov 04, 2011 at 18:30 UTC
POSIX::close() did the trick. Thanks a bunch!	[reply]