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

Owner: Nobody in particular
Requestors: obilodeau [...]

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

Subject: Timeout isn't honored in a program with threads
Download (untitled) / with headers
text/plain 793b
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 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
Download (untitled) / with headers
text/plain 596b
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().

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to