mk wrote:
>
>> the uncommon, the exceptional, case. If one could somehow turn off
>> exceptions, you can't even do a for loop: every for loop would become
>> infinite-- exceptions are how Python signals the end of an iterator.
>> Think about that, *every* for loop in Python suddenly breaks.
>
> Ouch.
>
>> Sure I can, but how do I get out of Python the info *what called
>> particular class/instance*? That is, how do I know who's the caller?
>>
>>
>> Um... run your code in a debugger.
>
> ..except the code in question is multithreaded and pdb is no good for
> that, and last time I checked, yappi was broken.
>
>>
>> That's what debugger's are -for-.
>>
>> "pdb" is a simple one. Various IDE's have more advanced ones.
>
> I tried using pdb on paramiko and my own threaded code, lost some hair
> in the process, and gave up. It's good for tracing the main thread,
> basically, not for threading.Threads.
>
>> I think you're better served showing us what, "I'm getting an exception
>> (on socket) handled..." actually means, what is actually happening with
>> real code and output, and getting pointers on where to look, then trying
>> to gather material to support an honestly impossible change :)
>
> I'm using a threaded library paramiko (probably by now half of this
> group is sick of hearing me saying this again). 2 of (rather broken)
> hosts (Solaris, Linux) are really, really slow when responding over SSH,
> like a minute for a key exchange. In paramiko, timeout doesn't work bc
> the timeout specified there is timeout for a socket and not for SSH.
>
> When calling transport.socket.close() via threading.Timer like this:
>
> def printandclose(self):
> print "\ntrying to close transport.sock"
> self.trans.sock.close()
> self.flag = True
>
>
> self.flag = False
> timer = threading.Timer(4, self.printandclose)
> timer.start()
> self.trans.start_client()
> timer.cancel()
>
> ... I'm getting this on the console:
>
> ERROR (9, 'Bad file descriptor')
>
> According to a guy who is very knowledgable on the library (thanks for
> all the help, James) this is result of catching socket.error somewhere
> in paramiko code, like "except socket.error".
>
> I need to find that place. On top of lack of proper handling of
> timeouts, this is important bc when calling paramiko SSHClient.connect()
> (which in turn uses the same machinery as transport.start_client IIRC)
> paramiko uses close to 100% of CPU when negotiating with such broken or
> unresponsive hosts.
>
> For my reasons, I need to get this fixed.
You could try to shadow the exception class with None:
>>> ZeroDivisionError = None
>>> try:
... 1/0
... except ZeroDivisionError:
... print "caught"
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
ZeroDivisionError: integer division or modulo by zero
Applying that technique on a module containing
try:
...
except socket.error:
...
#untested
import socket
class SocketWrapper:
def __getattr__(self, name):
return getattr(socket, name)
error = None
import module_using_socket
module_using_socket.socket = SocketWrapper()
Peter
--
http://mail.python.org/mailman/listinfo/python-list
