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.
I expect I will need several messaging buffers, and ring buffers tend to
be quite robust. Replacing the event buffer code with the macros made
testing easy.
id and z seem to always be 0.
Ironically, it turns out that the work needed for "int id" and "large"
struct nil init wasn't strictly necessary to get to this point, but
without having done that work, I wouldn't know :)
Such declarations were being lost, thus in the following, the id field
never got added:
typedef struct qwaq_mevent_s {
int id;
int x, y, z;
int buttons;
} qwaq_mevent_t;
With this, the VA is very close to being safe to use in a threaded
environment (so long as each VM is used by only one thread). Just the
debug file hash and source paths to sort out.
Other than consistency with printf(), I'm not sure why we went with the
printed size as the return value; returning the resultant strings makes
much more sense as dsprintf() (etc) can then be used as a safe va()
typedef is meant to create a simple renaming of a potentially complex
type, not create a new type. Keeping the parameter type alias info makes
the types effectively different when it comes to overloaded function
resolution, which is quite contrary to the goal. Does expose some
breakage elsewhere, though.
Other than its blocking of access to certain files, it really wasn't
that useful compared to the functions in qfs, and pointless with access
to qfs anyway.
The progs execution code will call a breakpoint handler just before
executing an instruction with the flag set. This means there's no need
for the breakpoint handler to mess with execution state or even the
instruction in order to continue past the breakpoint.
The flag being set in a progs file is invalid.
For technical reasons (programmer laziness), qfcc does not fix up local
def type encodings when writing the debug symbols file (type encoding
location not readily accessible).
The debug subsystem now uses the resources system to ensure it cleans
up, and its data is now semi-private. Unfortunately, PR_LoadDebug had to
remain public for qfprogs because using PR_RunLoadFuncs would cause
builtin resolution to complain.
It is now set to 0 when progs are loaded and every time
PR_ExecuteProgram() returns. This takes care of the default case, but
when setting parameters, pr_argc needs to be set correctly in case a
vararg function is called.
PR_SaveParams() is required for implementing the +initialize diversion
used by Objective-QuakeC because builtins do not have local def spaces
(of course, a normal stack calling convention would help). However, it
is entirely possible for a call to +initialize to trigger another call
to +initialize, thus the need for stacking parameter stashes. As a
bonus, this implementation cleans up some fields in progs_t.
