I announced the new desktop system at the very beginning of it’s development, the time since has been spent developing more of a structure for prototyping the desktop system and working towards resolving underlying weaknesses in my kernel & platform.
Design: Multithreaded Networked Desktop
The desktop system is designed in a fairly straightforward manner:
- A desktop server splits off into multiple threads to handle connections, rendering & input from different “client” programs
- Client programs connect to the server over standard socket APIs (until some faster mechanism can be negotiated over the protocol in the future)
This design is similar to some legacy graphics systems and also helps test features like networking and multithreading in the kernel, the downside being that it’s very exposed to any bugs or limitations of these features.
Solved: Lack Of Loopback Networking
The first problem with this approach was that I had to extend the networking code slightly to enable a “localhost” type loopback network.
This now appears to work, but may need some cosmetic changes to avoid people confusing it for a real network driver (right now it shows up like a normal network backend).
Problem: Multithreading/Wakeup Instability
While the client/server architecture works correctly on the new kernel & microps-based network stack in simple test cases the kernel will probably require some more troubleshooting before I can get it to work reliably with multiple threads and in different timing scenarios.
Multithreading code in the kernel has only been used for straightforward tests previously so some degree of “unexpected” behaviour was expected. Currently I’m having some problems with the secondary thread hanging when almost the same code seems to work in single threaded or forked-process situations, so this is likely a problem relating to unfinished multithreading support but will take a little while to figure out the exact problem.
While basic support for multithreading exists at the kernel level, the libc (C library) implementation currently has no support for multiple threads, so the current problems could just be a simple problem like malloc memory being corrupted due to a call in the second thread. In that case the fix will probably just be enabling locking in some libc subsystems.
Summary
It’s all still coming, and some more workarounds can be made if not every problem can be solved in the short term, but the kernel & libc code in particular will take a while to get to a stable point where I can easily develop & debug new programs on it!
This is part of the reason the desktop system is designed to run on Linux or elsewhere as well, making it easier to determine which bugs are in the desktop code and which are deeper in the system.