Skip Menu |

This queue is for tickets about the Net-Telnet CPAN distribution.

Report information
The Basics
Id: 54415
Status: open
Priority: 0/
Queue: Net-Telnet

People
Owner: Nobody in particular
Requestors: obilodeau [...] inverse.ca
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Timeout isn't honored in a program with threads
I'm using Net::Telnet inside a threaded perl program. Because of a bug in SIGALRM handling in perl, I need to define a global signal handler for SIGALRM otherwise perl bombs when telnet times out. See http://rt.perl.org/rt3/Public/Bug/Display.html?id=16807. So, if I don't set that global handler, when Net::Telnet times out, the program crashes. If I set a local signal handler it crashes too. If I set a global handler that does nothing, I can't know which thread hang so I can't recover gracefully. The thread running the Net::Telnet will eventually resume after a couple of minutes (like if I set Timeout to undef). I was wondering: Can't you use a timeout in the network system call instead of using alarm()? That would resolve my problem. Environment: perl v5.8.8 Linux 2.6.x
If I understand this correctly, it is a new feature request to use a non-blocking connect() instead of alarm() to end a Net::Telnet::open() that is over the timeout limit. The problem is non-blocking connect() varies with the OS. Some don't implement it. I do agree that this would be a good new feature for those OS's that do implement non-blocking I/O for connect(). I will try to put this in a later version of Net::Telnet. The workaround is to not use Net::Telnet::open() but rather to do the non-blocking connect() yourself and then pass the open socket handle to Net::Telnet::fhopen().