SQL in QuakeC

[Spike]

50ms = 20 fps.
two simultaneous frags = 10fps.
that's too slow.
especially if it needs to hit different parts of the disk. then its 100ms or so per kill/death/weapon, or worse depending on disk speed/disk fragmentation.

[Downsider]

You guys don't like multithreading.

[frag.machine]

Combining QuakeC VM and multithread may proof to be complicated.

Maybe later I'll try welding together FitzQuake and SQLite and run some performance tests (I'll need to write some QuakeC to exercise that too). It will be interesting, although a more humble approach than Motorsep is trying to achieve. For now I am focusing in my hud experiments.

EDIT: @Spike: true, but you're underestimating the power of data caching most RDBMS have nowadays. The delay hits usually are not constant, and they tend to become smaller if the same queries are repeated frequently over the same data collection. Besides, much of a database latency is due to network, actually, so there's some room for improvement.

[Spike]

QuakeC has no true stack, locals are globals. as are the return values from lots of functions, as is 'self'. QuakeC and multithreading really won't work, at least not true multithreading.
Having said that, FTE does have a 'fork' builtin, which walks the stack and clones the various values, thus:
if (fork())
{
bprint("hello from a thread\n");
sleep(5);
bprint("hello again\n");
abort();
}
will create a separate thread, and print two things with a 5 sec delay between.
However, the only things that it'll preserve are locals, self, and other. There's also no guarentee that self or other have not been freed/reused in the time the thread was sleeping for those 5 secs.
presumably instead of the two prints, you could do a open and a few reads+close. If there was a proper way to sleep such an excecution context until the query finished then it might be simpler to use.
But remember that players can drop from the server, ents freed, maps ended, etc, in the interim. A callback helps draw focus to this likely cause of errors.
Also, tying extensions in to other extensions can result in making it individually unportable, and thus useless for mods that want to target more than just one engine.

Engines using threads is the only way to get the most out of modern computers (no modern computers come with a single cpu, even phones tend to have two cores - though to be fair, one is generally dedicated purely inside the modem and a generation behind and not available to the OS). But QC is not able to make use of any of it directly.

[TimeServ]

The original SQL thing I implemented absolutely is overkill. I overkilled it as I wanted to make it all inclusive for any heavy usage and I also didn't care any about ease of implementation for other engines. For example the multiple servers thing... somebody wanting that complex of a setup will probably roll their own engine anyway. The closest I could ever see a regular mod doing is using a main DB connection with an SQLite local or ":memory:" database, but really I can't see an absolute need for that either.

I think you're underestimating the worst cases for database access though.. like say someone using a SQLite database on a Western Digital green label drive that seems to stall reads whenever it feels like. Within game play itself, a mod will most likely be doing stat collection (INSERTs) and most likely doesn't care about the completion except maybe on error. Also from practice SQLite doesn't do so well with many INSERTs within a short time (this is documented and there are workarounds but with caveats). This cost is easily avoided with an asynchronous callback. Unfortunately with asynchronous callbacks, that does make things like initial population queries on map start more awkward and you could run into queries orphaned from associated players/entities, but I think the potential cost of blocking database calls is too great to avoid.

Anyway, getting rid of multiple server support removes the need for the serveridx parameter everywhere. I'd probably go ahead and abstract out connect/disconnect and remove the error builtin (moving the error string to callback). I think the sv_sql_* parameters should be enough. I don't see the need for a database connection string-style interface. Maybe accessing Windows data sources would be useful but I don't know, I never really cared for configuring that thing.

Last things that concerns me is that QuakeC strings aren't UTF-8 safe which could come up if someone wanted to store netnames or something. Also concerning QuakeC multithreading I'd like to know how findchains close in execution to each other would work.