DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44402>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44402 ------- Additional Comments From [EMAIL PROTECTED] 2008-02-16 14:23 ------- I think I have to correct myself in two points. 1. On APR trunk there are better implementations for apr_atomic_casptr which no longer use a mutex, but native platform processor / OS features. So in contrast to my first assumption there could be a performance degradation by your patch on trunk, which would be bad. 2. The race scenario you described cannot happen in this way, because it assumes that multiple threads pop pools from the list in parallel. This is not the case as only the listener thread does this. What happens in parallel are: - Multiple pushes to the list - (Multiple) pushes to the list and a pop OTOH I still believe that there is some kind of race scenario as your patch showed that the error goes away if the locking / syncing is changed here. So maybe its only a different scenario (that I haven't figured out so far) or there is a bug in apr_atomic_casptr. Do the same crashes happen with trunk? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
