"JZ" == John Ziniti <jziniti@speakeasy.org> writes:
John; Could you put this in the collector.... JZ> Sure
I'm following up here, perhaps a little late. John also reported this bug in the Python bug tracker at SF. I think he's right that asyncore should catch EINTR and retry. The right thing, in probably every case, is to retry the select. Thus, asyncore should be doing it and not burdening every application (like Zope) with the need to add a try/except. JZ> Let me apologize and clarify. Zope *does* crash if there is no JZ> try/except around the select, at least in the way that I think JZ> of crashing. It needs to restart itself in any case. Right. JZ> I am pretty sure EINTR *is* the problem, but when I add the try, JZ> it seems that a later call to accept() throws EWOULDBLOCK (??). JZ> This doesn't crash Zope, but brings down the FCGI and PCGI JZ> Servers. Did you retry the select() or did you do something else? JZ> See the trace below. I added the print 'system.error' line JZ> inside the except block. The last error in your traceback is quite interesting: JZ> ------ 2001-08-16T13:16:01 PROBLEM(100) ZServer warning: server JZ> accept() threw EWOULDBLOCK ------ 2001-08-16T13:16:01 ERROR(200) JZ> ZServer uncaptured python exception, closing channel JZ> <select-trigger (pipe) at 248024> (exceptions.OSError:[Errno 11] JZ> Resource temporarily unavailable JZ> [/u01/zope/lib/python2.1/asyncore.py|poll|101] JZ> [/u01/zope/lib/python2.1/asyncore.py|handle_read_event|389] JZ> [/u01/zope/Zope-2.4.0-src/ZServer/medusa/thread/select_trigger.py|handle_read|77] JZ> [/u01/zope/lib/python2.1/asyncore.py|recv|341] JZ> [/u01/zope/lib/python2.1/asyncore.py|recv|523]) John Heintz has been seeing a similar problem with the latest beta of ZEO 1.0. It doesn't really make sense that select() reports the socket is ready for reading, but recv() fails with EWOULDBLOCK. Is it easy to reproduce this error? Could you isolate a test case that I could run locally? Also, what platform are you running on? Jeremy