Goal:

with eventlet removal in openstack, services are expected to migrate towards a combination of threaded and multiprocessing models.    The use case for multiprocessing has been to allow concurrent Python code to run that can take advantage of multiple CPU cores, since the GIL prevents multithreaded code from achieving parallelism.  with the introduction of free threaded builds, this is no longer the case.

Acceptance Criteria:

• free threading introduces many new race conditions in any concurrent code, these need to be identified and fixed and robust within CI
• libraries such as greenlet may or may not support threading, or may need testing as they come on board with support.   or such libraries need to be avoided (e.g. eventlet removal)
• with eventlet removal, it's not known if some openstack utiltiies may make use of python asyncio or not.   SQLAlchemy's asyncio support depends on greenlet.
• SQLAlchemy 2.0 installs greenlet by default with no easy way to disable this.   SQLAlchemy 2.1 has changed this so that greenlet is truly optional.   To the degree greenlet is not well supported on free threading may also drive openstack to run on a "greenlet free" backend in order to have the best support on free-threaded (or maybe greenlet will be shown to be robust on free thredaing)

Open questions:

• What race conditions exist in threaded openstack?
• What improvements can be made to openstack regarding current reliance on multiprocessing that can be migrated to plain threads?
• can openstack run on a "greenlet free" environment?
• does any part of openstack expect to use Python asyncio with database support?