mirror of
https://git.code.sf.net/p/quake/quakeforge
synced 2025-02-22 19:51:54 +00:00
bd98d1d9fb
So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side. |
||
|---|---|---|
| .. | ||
| .gdbinit | ||
| builtins.c | ||
| event.h | ||
| main.c | ||
| Makefile.am | ||
| progs.src.in | ||
| qwaq-app.r | ||
| qwaq-bi.c | ||
| qwaq-curses.c | ||
| qwaq.c | ||
| qwaq.h | ||