The fasteners lib in version 0.15.0 removed the
threading.current_thread workaround for eventlet[1] because eventlet
seemed to fixed the current_thread issues tracked in [2]. However the
fix for [2] only fixed half of the problem. The threading.current_thread
call works if it is called from thread created by eventlet.spawn.
However if the thread is created with eventlet.spawn_n then
threading.current_thread is still broken and returns the ID of the
python native thread.
The fasteners' ReaderWriterLock depends heavily on
threading.current_thread to decide which thread holds a lock and to
allow re-entry of that thread. This leads to the situation that
multiple threads created from spawn_n could take the same
ReaderWriterLock at the same time.
The fair internal lock in oslo.concurrency uses ReaderWriterLock and
as a result such lock is broken for threads created with spawn_n.
Note that this issue was raised with eventlet in [3] when the nova team
detected it via a direct usage of ReaderWriterLock in the nova test
code. As [3] did not lead to a solution in eventlet nova implemented a
nova local fix for the test code in [4].
However now we detected that oslo.concurrency is affected by this issue
as well.
This patch restores the workaround that was removed by [1].
Note that a fasteners issue [5] also opened to restore the
workaround[1].
Reviewed: https:/ /review. opendev. org/c/openstack /oslo.concurren cy/+/855714 /opendev. org/openstack/ oslo.concurrenc y/commit/ ee3f73a13379a79 282325906787aae 7da0f6ac27
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit ee3f73a13379a79 282325906787aae 7da0f6ac27
Author: Balazs Gibizer <email address hidden>
Date: Sat Sep 3 15:35:35 2022 +0200
Fix fair internal lock used from eventlet.spawn_n
The fasteners lib in version 0.15.0 removed the current_ thread workaround for eventlet[1] because eventlet current_ thread current_ thread is still broken and returns the ID of the
threading.
seemed to fixed the current_thread issues tracked in [2]. However the
fix for [2] only fixed half of the problem. The threading.
call works if it is called from thread created by eventlet.spawn.
However if the thread is created with eventlet.spawn_n then
threading.
python native thread.
The fasteners' ReaderWriterLock depends heavily on current_ thread to decide which thread holds a lock and to rLock at the same time.
threading.
allow re-entry of that thread. This leads to the situation that
multiple threads created from spawn_n could take the same
ReaderWrite
The fair internal lock in oslo.concurrency uses ReaderWriterLock and
as a result such lock is broken for threads created with spawn_n.
Note that this issue was raised with eventlet in [3] when the nova team
detected it via a direct usage of ReaderWriterLock in the nova test
code. As [3] did not lead to a solution in eventlet nova implemented a
nova local fix for the test code in [4].
However now we detected that oslo.concurrency is affected by this issue
as well.
This patch restores the workaround that was removed by [1].
Note that a fasteners issue [5] also opened to restore the
workaround[1].
[1] https:/ /github. com/harlowja/ fasteners/ commit/ 467ed75ee1e9465 ebff8b5edf45277 0befb93913 /github. com/eventlet/ eventlet/ issues/ 172 /github. com/eventlet/ eventlet/ issues/ 731 /review. opendev. org/c/openstack /nova/+ /813114 /github. com/harlowja/ fasteners/ issues/ 96
[2] https:/
[3] https:/
[4] https:/
[5] https:/
Closes-Bug: #1988311 c9bd0b94c593567 d537b4c1112
Change-Id: Ia873bcc6b07121