[p00r]

Is really no need for a multithread module for amxmodx ??

[BAILOPAN]

The AMX/Small machine (which is the scripting backend to Admin-Mod, AMX Mod, and AMX Mod X), is not thread safe.

Simply put, if two threads are modifying the state of the Small machine at once, it can seriously corrupt the state of the plugin.

This is why the multithreading module by dJeyL back in the AMX Mod 0.9.3 days simply crashed or caused weird errors most of the time.

In order to make the machine thread safe, we'd need to put mutex locks on the amx_Exec routine - which basically defeats the point of making it safe anyway, since the execution of one callback would interrupt the main worker thread of the HLServer.

so, sorry, but I don't think we'll try this it wouldn't be a lot of work, but it would have no clear benefit or even a detrimental one.

[Johnny got his gun]

I can only see one need so far (there could be more) to have multithreaded possibilities: sql communication. SQL in realtime environments sucks to be honest.

I had an idea to "enhance" the DBI a little by giving the scripter and/or end user (server admin) the possibility of choosing what SQL module should take care of a certain plugin. This would assume that you could load several SQL modules at once, with one being the default one catching all "undirected" SQL calls.
That way for instance you could run DB intensive plugins (think WC3) using a faster SQL alternative like sqlite, and at the same time you could still run some other plugins with few unintensive SQL calling that could make use of distant *sql dbs just because they don't need to update so frequently (think stats plugins updating data at map changes).