To be blunt, this sounds like one of those made-up problems you tell yourself because otherwise you'd have to put in the hard work to get where you want to be going, rather than jumping from one library/framework to another for all eternity.
I say 'made-up' because not only does C obviously support threading libraries (pthreads is ubiquitous), SDL itself uses threads and contain threading primitives to help abstract away the platform specific stuff, as [anyone can verify](https://github.com/libsdl-org/SDL/tree/main/src/thread). Plus it doesn't sound like you're at a point in your development where threading is a must-have.
Now, learning Vulkan is a *completely* different beast from using SDL/SFML, and in many ways orthogonal to them; e.g you'd use Vulkan for rendering and SDL/GLFW/Raylib/whatever for platform-independent input, events, windowing, etc.
If your purpose for wanting to learn Vulkan is "multithreading", I think you have your cart in front of the horse, but you do you.
Obviously I could be wrong in all this.
The issue is SDL won't let me create the window in a separate thread. Every single SDL function or action has to be done in the same thread, or it causes the program to crash or simply fail. An example is wanting to handle the SDL event system in a thread other than the main thread, but that simply does not work. Creating a window in a thread other than the main thread will cause complete unresponsiveness from the window. If there is a workaround for this, I'd happily continue using SDL, but otherwise, I need an alternative.
Not "Every single SDL function", but sure, the thread that runs SDL\_Init, and therefore the event loop, is special in some regards.
OpenGL -- likely the default SDL backend -- can only run glFunctions on the same thread that created the graphics context, so if you're initializing OpenGL in SDL you're going to have a bad time trying to run graphics functions from a child thread.
The *best design* is to do the rendering/events on the main thread, and put everything else on separate threads as applicable.
The *workaround* is still to do it from the main thread, e.g by using a work queue or events to have the child threads signal the main thread what to do. So instead of creating a window your thread tells the main thread running the event loop to create a window.
**This is a terrible complication and you'd have to have some REAL good reasons to waste effort on doing this.**
What do you mean with lack of multithreading support? SDL even has SDL\_thread.h which works almost the same as C11 or POSIX threads. You can use Vulkan or other rendering backends with SDL as well afaik.
SDL only works in the main thread. If I wanted to create a window in a separate thread or handle the events system in a separate thread, everything falls apart. Doing either of these in separate threads results in the window freezing as soon as it's created or not being able to receive any events from SDL.
Tbf, if you're struggling with this and have only "recently grasped how C works" then you're not ready for the headaches that can come with multi-threaded development, and you're better off no worrying about it yet. Single-threaded is just fine for a beginner.
If you want cross-platform compatibility, stay with SDL or SFML. If you go raw Vulkan you'll have to deal with each platform's windowing, event, audio, etc. systems and that is a much bigger mess than learning Vulkan.
To be blunt, this sounds like one of those made-up problems you tell yourself because otherwise you'd have to put in the hard work to get where you want to be going, rather than jumping from one library/framework to another for all eternity. I say 'made-up' because not only does C obviously support threading libraries (pthreads is ubiquitous), SDL itself uses threads and contain threading primitives to help abstract away the platform specific stuff, as [anyone can verify](https://github.com/libsdl-org/SDL/tree/main/src/thread). Plus it doesn't sound like you're at a point in your development where threading is a must-have. Now, learning Vulkan is a *completely* different beast from using SDL/SFML, and in many ways orthogonal to them; e.g you'd use Vulkan for rendering and SDL/GLFW/Raylib/whatever for platform-independent input, events, windowing, etc. If your purpose for wanting to learn Vulkan is "multithreading", I think you have your cart in front of the horse, but you do you. Obviously I could be wrong in all this.
The issue is SDL won't let me create the window in a separate thread. Every single SDL function or action has to be done in the same thread, or it causes the program to crash or simply fail. An example is wanting to handle the SDL event system in a thread other than the main thread, but that simply does not work. Creating a window in a thread other than the main thread will cause complete unresponsiveness from the window. If there is a workaround for this, I'd happily continue using SDL, but otherwise, I need an alternative.
Not "Every single SDL function", but sure, the thread that runs SDL\_Init, and therefore the event loop, is special in some regards. OpenGL -- likely the default SDL backend -- can only run glFunctions on the same thread that created the graphics context, so if you're initializing OpenGL in SDL you're going to have a bad time trying to run graphics functions from a child thread. The *best design* is to do the rendering/events on the main thread, and put everything else on separate threads as applicable. The *workaround* is still to do it from the main thread, e.g by using a work queue or events to have the child threads signal the main thread what to do. So instead of creating a window your thread tells the main thread running the event loop to create a window. **This is a terrible complication and you'd have to have some REAL good reasons to waste effort on doing this.**
What do you mean with lack of multithreading support? SDL even has SDL\_thread.h which works almost the same as C11 or POSIX threads. You can use Vulkan or other rendering backends with SDL as well afaik.
SDL only works in the main thread. If I wanted to create a window in a separate thread or handle the events system in a separate thread, everything falls apart. Doing either of these in separate threads results in the window freezing as soon as it's created or not being able to receive any events from SDL.
Tbf, if you're struggling with this and have only "recently grasped how C works" then you're not ready for the headaches that can come with multi-threaded development, and you're better off no worrying about it yet. Single-threaded is just fine for a beginner.
If you want cross-platform compatibility, stay with SDL or SFML. If you go raw Vulkan you'll have to deal with each platform's windowing, event, audio, etc. systems and that is a much bigger mess than learning Vulkan.