At 9:46 PM -0500 12/19/05, John E. Malmberg wrote: >I am testing a fix for this problem,
I have not seen the accvios or stack corruption lately, but some of those while loops really should be for loops or take other steps to make sure we don't walk off the end. In this case that would have given us a predictable failure instead of consuming pagefile until quota or system limits intervened. > and I am seeing a hang on the test [.t.op]threads.t > >Is this a known problem? > >1..4 >ok 1 - fresh_perl - delete() under threads >ok 2 - fresh_perl - weaken ref under threads >ok 3 - fresh_perl - weaken ref \#2 under threads ># parent 471639: continue ># parent 471639: continue ># parent 471639: waiting for join ># kid 1 before sort ># kid 2 before sort ># kid 2 after sort, sleeping 1 ># kid 1 after sort, sleeping 1 ># kid 1 exit ># parent 471639: thread exited ># parent 471639: waiting for join > >[test hangs here.] I have occasionally seen hangs when testing a threaded build, though if you kill the subprocess and run it again it's generally not reproducible. I suspect our homegrown pipes need a good dose of thread safety. Probably everything currently wrapped with: sys$setast(0); ... sys$setast(1); should also be wrapped with: MUTEX_LOCK(&my_mutex); ... MUTEX_UNLOCK(&my_mutex); And then there is the issue of initializing and maintaining those mutexen, and whether there should be one per pipe, etc. And there is the added issue that ASTs block other ASTs, but ASTs do not block threads. So there are some AST routines that probably need threads locked around critical sections. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
