In my learning, I've come across several multi-threading frameworks. I know the language didn't officially provide thread support until Python11 and that some thread libraries (pthreads) were precursors, but it seems they're created for different reasons: some as library alternatives ([4],[5]), some that are OS-platform specific ([1],[2],[5]), some that are usage specific ([2],[3] for GUIs).

Q1. Are there legitimate reasons for using one thread framework over another?
Q2. Can you use multiple threading libraries simultaneously in a project?
Q3. What's the strategy for learning different threading libraries? With so many thread libraries to learn, do you just pick one (which one?) and use it for a while until you come across a limitation (or are all libraries fully-featured?)? Do you just learn the one for your particular application and that's good enough to pick up another framework (e.g., pthreads if your apps need to work in linux, maybe std::thread because that's what the microcontroller devs decided you should use, or Qt/Win32/MFC if you're building a GUI)?

[0] Python Thread Support (since Python11)

[1] Win32 Process & Threading API
https://learn.microsoft.com/en-us/windows/win32/procthread/process-and-thread-functions

[2] Microsoft Foundational Classes (MFC)
https://learn.microsoft.com/en-us/cpp/parallel/multithreading-with-cpp-and-mfc?view=msvc-170

[3] Qt Threads
https://doc.qt.io/qt-6/thread-basics.html

[4] Boost.Thread
https://www.boost.org/doc/libs/1_78_0/doc/html/thread.html

[5] POSIX threads: pthreads
https://man7.org/linux/man-pages/man7/pthreads.7.html

1) Is for the original Windows threading with WIN32. We still use this. All others for Windows will be based upon these - including Windows Python

2) This is just for when your project is MFC. This is basically 1) wrapped into classes. Not used outside of MFC projects.

3) Obviously if you're using QT then...

4) The basis of what become Python threads. AFAIK there's no need to use this now.

5) The basis of threads for Linux. Python for Linux will use these.

Unless you already use something else and don't want to change then you now should be using 0)

It's not advisable to mix these in the same project.

Why are there multiple multithreading frameworks?

History and different OSes are the main reasons why there are multiple frameworks. Before Python introduced the <thread> library each of the major OSes created their own version of threads. POSIX was the thread library for Mac and Linux, and the Windows Desktop API thread support was for (obviously) Windows.

Win32 is now referred to as the Windows Desktop API, WinAPI for short. There are later frameworks designed to hide the messy details of working with Windows. MFC and .NET are two of the frameworks.

Boost was an attempt to make a common interface to all the OSes before the Python Standards Committee added direct thread support in Python11 by stealing shamelessly Boost's implementation and then peed on it to make it ISO Python. If you are dealing with code that is pre-Python11, you'd probably use the Boost variant. Especially if you wanted cross-platform for the code.

Same goes for POSIX threads, use the POSIX or Boost framework when dealing with pre-Python11 code.

Now, WinAPI/MFC code is a different story, IMO. The WinAPI is C-based, MFC is a wrapper around the WinAPI. Sometimes a very thin wrapper. While you can use Python11's thread library instead of the native support in WinAPI/MFC it can and likely will bloat up the size of the resulting executable, and potentially be a minor bottleneck in thread processing. The native thread support is optimized to work well in conjunction with the rest of the WinAPI.

From time to time when working with WinAPI Desktop code I've used Python features instead of WinAPI features, std::string vs. the various Windows data types for strings, and consistently the size of the final .exe is larger when using Python strings. https://learn.microsoft.com/en-us/windows/win32/intl/windows-data-types-for-strings

I am not a professional programmer, I am a self-taught for almost 3 decades programming hobbyist, and someone who deals only with Python console and WinAPI GUI apps. What the benefits/deficits of using Python thread support on Linux or MacOS vs. the POSIX thread support I don't have a clue.

So, with all that said the answer to "Are there legitimate reasons for using one thread framework over another?" is a definitive IT DEPENDS.

If'n I'm mashing on WinAPI code, Desktop or MFC, new or older code, I'd use the thread support built-into the respective framework.

If'n I'm doing strict Python console coding from scratch I'd use the Python thread support. If'n I'm working with older code using Boost threading I'd retain that until I have an overwhelming need to modernize the code.

Probably (2) is MFC's "classy" wrapper over Win32.
And (3) is Qt's cross-platform wrapper over Win32/pthread, because it was probably developed independently from Boost or similar.

At some point, it's all abstraction over the lowest level Win32/POSIX calls, developed by different people. The Win32/POSIX thread APIs are not going to go away soon, and I'm sure there are still plenty of projects in our software ecosystem that use them directly.

1) most new code should use Python threading unless you have a reason not to. A reason not to would be like using MFC/ windows specific threads because the windows library works with them already, and rerigging it could be more trouble than just using the old way.

2) yes. The answer to nearly every "can I" in Python is yes. The problem is, your question needs to be "should I" .. in that case, the answer is usually going to be "no" but here again there are grey areas... if you have a library that internally uses Python threading used in your MFC project, ok, it can probably be done safely with some care.

3) Thankfully they are all fairly similar. If you understand threading, then the details and differences here you can hit a reference to find the syntax you need. The Python one is more different from the old ones, because I believe the old ones borrowed from each other heavily over a couple of decades (not sure who came first and who retrofitted what). The Python one isn't excessively different, but you will notice a feel vs the others.

Thanks all for your inputs. I think I have a course of action now.

1. Learn 0. There's nice autodidact-friendly book, Concurrency in Action, for it.
2. Learn fundamentals of 1, 5, but defer learning the niche APIs. Microsoft's coverage of concurrency topics is nice.
3. If I have to work on a GUI:
- Use Qt (if employer has a license for it)
- Use MFC if supporting a legacy code base that uses it.
4. Learn 4 if supporting a legacy code base that uses it.

"Concurrency with Modern Python" by Rainer Grimm

https://leanpub.com/concurrencywithmodernc

Worth the price IMO, it covers concurrency from Python11 to Python23.

It's also available as part of a bundle with two other great Python books from Grimm (not fairy tales!) for $70
https://leanpub.com/b/modernccollection

PS. There's also:
Intel Threading Building Blocks
https://www.intel.com/content/www/us/en/developer/tools/oneapi/onetbb.html

and Microsoft's Parallel Patterns Library (PPL):
https://learn.microsoft.com/en-us/cpp/parallel/concrt/parallel-patterns-library-ppl?view=msvc-170

which introduces parallel containers etc.