[Slice]

The more correct statement would be "the scripts run on a single thread". Any incoming info from the bit-stream is put in a buffer/queue then called when the PAWN script isn't busy. By default, the server will wait for SQLite to finish writing/reading to the file - you can allow it to do this in a different thread by running the following query.

pawn Code:

db_query( db, "PRAGMA synchronous = 0" );

Why the dialos is delayed is simply because:

• Player types command.
• Command is recieved by the server.
• After ~5ms, the server calls OnPlayerCommandText.
• The outgoing data to show the dialog is sent to Player.
• Player recieves the data and the dialog is shown.

So basically, PAWN can't be doing two things at a time.

How MySQL plugins are threaded is when they get the action to perform, a new thread is started and when the data is ready to be sent back into the PAWN script it will call a PAWN callback when it isn't busy (usually at ProcessTick).

Player position and everything does go through the PAWN script before it is sent to the other clients - through OnPlayerUpdate. That callback is called every time any player-related info is about to get sent to the other clients. If you return 0 in OnPlayerUpdate, the server won't send that information. This clearly indicates it has to go through the PAWN thread just like everything else.

I hope you understand me a bit better now.