Quote:
Originally Posted by joeyeyey
Okay, I see. But is the fps on the server gonna drop without threaded queries? Or is the plugin gonna lag? Cause when wanting a !top10 list, its not a big deal if the plugin lags for a second.
So a nice rule would be to always end the code block with the TQuery when using one? And the rest needs to be in the callback if associated to the DB?
|
Quote:
Originally Posted by joeyeyey
Yeah I understand know. I thought each plugin had its own thread. Thanks for the explanation!
Is there a way to get the client into the callback? I tried by simply send them in a parameter for the SQL_TQuery, but without success.
|
No, not every plugin has its own thread. The SM VM is entirely single threaded* and all plugins run alongside the main game thread. Source engine functions are not thread safe (my source of info is from BAILOPAN). In other words, all your plugins and the main game server functions are ran on ONE thread only. This is for good reason too - dealing with locks and all the associated bullshit that comes with threads is not something you really want to deal with. (I hope this gives you a much better insight/perspective on how the server works and how plugins are ran on the server.)
Making the threaded query call the last thing of a function is a good way to work around the problem, although it's not ALWAYS true that it should/must be the last thing at the bottom. Nonetheless, you should always use threaded queries to ensure the best performance of your server. That way, if something does hiccup in the database-end (in the case of sqlite, say the I/O was delayed because the OS was busy doing I/O to disk somewhere else) the server will not jam in the middle like Miu has explained.
*There are exceptions: C++ extensions can run code on a separate thread, but they cannot touch sourcepawn variables or anything owned by sourcepawn. (or rather, they SHOULDN'T, since sourcepawn variables are not thread-safe. You probably COULD manipulate them but it's probably NOT a good idea to do so.) Since the SQL driver is a C++ extension it can run on a separate thread.
(That probably got more technical than you wanted... lol. And I'm sure like about 10% of the stuff I said is semi-wrong since it's subject that's slightly out of my knowledge of VMs and threads.)
Also, if you want to pass more than 1 piece of data into the threaded query callback, you can use this shitty workaround that I came with: Create a handle and use that handle to make a trie. Shove whatever data you want to be sent to the callback in the trie. Then, pass in the handle as the optional parameter. On the threaded query callback, use the handle to get the stuff out the trie, and then continue from there. It's slightly unnecessary work that the server has to do, but unless you're running the server on a pentium 4 processor or something on that order of magnitude of shit, it should not be a big deal. This is what I did for a plugin I was writing where I had to pass the client index, a weapon slot, the weapon's definition index, and the weapon classname (so 4 pieces of data) into the threaded query callback, and only a trie was able to solve this problem. (You probably could also use a keyvalue handle as well, or some container that uses a handle.) The compiler only saw it as 1 variable being sent to the callback function, even though internally it had 4 pieces of data in it.
Linear Mode
