https://bz.apache.org/bugzilla/show_bug.cgi?id=65159
--- Comment #15 from WJCarpenter <[email protected]> --- > > I don't know if the Apache/APR ecosystem has atomic operations. > > Yes, atomic operations are available. See > http://apr.apache.org/docs/apr/1.6/group__apr__atomic.html I don't know if using that is even necessary. Without looking at the generated machine code, I would expect that pre-incrementing a short is either atomic on modern architectures or is usually of an acceptably small window of time. Another way to eliminate the race could be to make the "thread index" a true indicator of the thread. I still don't know the relationship between r->connection->id and the current apr_thread_t. So, I don't know the difficulty of switching to that approach. > I'm fan of the KISS principle ([1]), so if a solution with atomic works, I > think it would be a cleaner solution. Me, too. I don't want to suggest a big change for the duplicates we started noticing if we can find a nice simple change to the 2.4.46 code that resolves the problem that triggered the patch. The code even in 2.4.46 has some complications that make it tricky to follow. It builds up a unique ID record and then goes to a lot of trouble to encode just the bytes that matter and not any padding bytes. Maybe the original author anticipated that unique ID record becoming more complex over time. As it is, it would be simpler to keep track of the per-process ROOT in a static, keep the counter as another static, and then just directly encode that small number of pieces. Or copy that small number of pieces into a scratch buffer if that makes the encoding loop simpler. The entire unique ID record is subject to the race condition, but it's only the counter that makes any difference in that race. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
