Yeah, I actually have this in my own APC tree where I have turned the locking into a set of macros and redefined them to do things slightly differently.  I have yet to see a bug report that in any way suggests that this might be a problem though, but I agree that theoretically it could be.

Committed to CVS

this seems didn't solved conflict between zend_timeout and apc.

HANDLE_BLOCK_INTERRUPTIONS() only do with apache1.3
not against zend_timeout of ZendEngine
using HANDLE_BLOCK_INTERRUPTIONS still possible have possible timeout in the middle.

maybe we can implement the BLOCKs ourself?
maybe we can use zend_try? zend_deactivate() did so,
but that's end of script exec. zend_try in the middle of script exec (e.g.: include()) may break zend_timeout(), unless we re-throw (zend_bailout again)

something i forgot to mention:
1. once a time, i got my script timedout on include() statement, i guess there's no place where php can spend such long time in "parsing"
this seems apc is waiting fot lock, i'm not sure, 
but the fact is "timeout still triggered"
well, this is just a "week"(can't make sure) instance.

2. recently, i get some "bad response" when a php file is updated, but re-request(auto done by browser) is ok, cached opcode is updated too(with new php run the page).
strange: no core dump.
by clearing the cache, everything is fine.

Closing this, block interruptions are used, for 1.3, N/A for anything else.

The original request is therefore satisfied.