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
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 793
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 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
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18052-1356355571-1840.54415-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 596
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 Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.