[ThantiK]

I dont know the core workings about all of this stuff, but would it be possible to design SourceMod from the ground up to minimize any processing needed from the server process itself?

I know a lot of the reason that we have to focus on just in time compiling and pure processor code, is because large bits of code tend to do weird things and throw off accuracy and hit determination of the server.

I'd like to see SourceMod be passive, so the calculations and processes it takes care of, dont effect the server process itself. Would this be possible? Reason being, is because even I have noticed some plugins obviously change hit registration. I really feel if we can't make it somehow passive, then we need to focus on making the code as FAST AS POSSIBLE. To avoid such things as the registration being thrown off.

[BAILOPAN]

No



I'll expand on this. The HLDS server never has, and probably never will, allow for nice threading like this. It's a huge amount of work to make something threading safe, especially for something complicated like a game engine - which requires precision and compensation. You don't know when the OS will process threads - so sensitive stuff can get very intricate.

For SourceMod, there's no reason to do this. Say the server is about to process a command - under your model, this should be threaded - but by the time metamod has finished the call, all of the things relevant could have been deallocated/destructed. Then when the thread finally executes, bad things happen.

Case in point, the reason mthread module never worked is because people didn't look into these inconsistencies.

Now, I haven't announced this publically yet, but one version of SourceMod will be bundled with an embedded web server. This will be threaded. SourceMod will also be making many database calls - these can't be threaded, but there aren't too many situations in which this is a problem.

[Dygear]

Originally Posted by BAILOPAN Now, I haven't announced this publically yet, but one version of SourceMod will be bundled with an embedded web server. This will be threaded. SourceMod will also be making many database calls - these can't be threaded, but there aren't too many situations in which this is a problem.

Nice touch, so I am thinking ... something like stats on a webpage, all you need is a MySQL server/database.

[imported_malex]

Originally Posted by BAILOPAN Now, I haven't announced this publically yet, but one version of SourceMod will be bundled with an embedded web server. This will be threaded. SourceMod will also be making many database calls - these can't be threaded, but there aren't too many situations in which this is a problem.

Why bother with an embedded web server? If SourceMod will be so database-driven, as you hint, why not have a separate process access that same database? This would mean you could simply code a php page or a cgi or whatever to be run by apache, and not have to worry about the HTTP protocol. You could offload other things to separate processes also, TK punishing comes to mind.

\malex\

[BAILOPAN]

No, interaction with the HL engine on a multithreaded basis is dangerous and complicated. I'm not even going to attempt it.

It's not as easy as you make it out to be... multithreading isn't just a catch all solution, it's quite complicated. An embedded web server is useful if your host doesn't have webspace or MySQL access - it would be much faster than the remote version (the only limitation of the local version is that it couldn't manage mutiple servers).

The web interface would not be interacting with sourcemod at all. It only serves to modify the configuration through SQL queries. However, the SourceMod engine would be using those same queries to do things like authentication. That's why the DB is a two way system, it can't be threaded. But the web server can.

Another issue you guys seem to miss is that multithreading is not that easy! Everything works on callbacks, for example, I get constantly bugged to "just make mysql multithreaded". The API would have to be totally redone, and it would look terrible, based entirely on callback functions. Observe:

new Sql:sqlID

mysql_connect(..., "callbackGetConnect")
mysql_query(sqlID, query, "callbackGetResult")

public callbackGetConnect(Sql:id)
{
   sqlID = id
}

public callbackGetResult(...

Et cetera. You have no way of knowing WHEN it will execute, IF it will ever execute. Then you need to implement object locking, semaphores, etc... it's way too much work for something that wouldn't even work right, as in gaming engines things need to be timed linearly, and so many events can happen in one sequence, there's no telling what would happen by the time the OS decides the thread should be called.

[PM]

I think making mysql is possible in a nice way and I would attempt to do it if you want. Making SourceMod Core multithreaded is a bad idea.

[Li0n]

and what about a "SM'thread module" with some limitations like local variable, no string argument, params specific or anything else ?!

bref, a thread module with specific documentation of what we can do or not in small script.