Re: [Zope-dev] Possible 'bad' with Client.py and urllib
Chris Withers writes:
.... urllib & Client block Zope .... That would suggest a bug in Python's socket implementation:
its "makefile().read" method would not release the global interpreter lock. Dieter
Dieter Maurer wrote:
Chris Withers writes:
.... urllib & Client block Zope .... That would suggest a bug in Python's socket implementation:
its "makefile().read" method would not release the global interpreter lock.
Do you think this is likely? If so, where would I go to report it, or maybe it's perhaps already fixed in Python 2.0? That said, this problem only started manifesting itself when the target of the urlopen or Client.get was a Python Script. It had been working fine before when the target was DTML Method. What with the Byte Code hacks, etc, in Python Scripts, I wonder if that isn't maybe the problem. Has anyone got any ideas how I'd go about inestigating this? cheers, Chris
Chris Withers writes:
Dieter Maurer wrote:
Chris Withers writes:
.... urllib & Client block Zope .... That would suggest a bug in Python's socket implementation:
its "makefile().read" method would not release the global interpreter lock.
Do you think this is likely? If so, where would I go to report it, or maybe it's perhaps already fixed in Python 2.0? If your Zope blocks, then multi-threading seems to be disabled: either because the global interpreter lock was not released or all threads are used up.
The Python bug tracker is at Sourceforge (hopefully linked from http://www.python.org). "comp.lang.python" may be of help, too.
That said, this problem only started manifesting itself when the target of the urlopen or Client.get was a Python Script. It had been working fine before when the target was DTML Method. Strange, there should be no difference between DTML and PythonScript in this respect.
What with the Byte Code hacks, etc, in Python Scripts, I wonder if that isn't maybe the problem. I would not expect this.
Has anyone got any ideas how I'd go about inestigating this? You could try to figure out in what state Zope is when it blocks. Does is consumes time? Maybe, you can use a debugger to determine in what state the various threads are. This may give us a hint where the block is established.
Dieter
Has anyone got any ideas how I'd go about inestigating this? You could try to figure out in what state Zope is when it blocks. Does is consumes time? Maybe, you can use a debugger to determine in what state the various threads are. This may give us a hint where the block is established.
Hmmm, looks like I'm going to have to punt on this one due to my own time shortage :-( If anyone does find something odd in here, please let the list know ;-) cheers, Chris
participants (2)
-
Chris Withers -
Dieter Maurer