User:Ccw: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
== == | == == | ||
=2011 October | =2011 October 22= | ||
== | ==How do you solve a problem like my server stalling?== | ||
''Answer: coroutines and threaded database access'' | |||
=====Propose 3 new database access functions:===== | |||
==dbQuery== | |||
<syntaxhighlight lang="lua"> | |||
handle dbQuery( sting query ) | |||
</syntaxhighlight> | |||
*'''dbQuery''' starts a database query and returns a handle | |||
==dbPoll== | |||
<syntaxhighlight lang="lua"> | <syntaxhighlight lang="lua"> | ||
table dbPoll( handle[, int timeout = 0, bool autoFree = true ] ) | |||
</syntaxhighlight> | </syntaxhighlight> | ||
*'''dbPoll''' returns the result of the query started with the supplied handle, or nil if the query has not completed yet. Setting timeout above 0 will make the function wait a bit longer if the query is not ready. A timeout of -1 will make it wait for ever. If autoFree is true, the query handle gets automatically freed when '''dbPoll''' is able to return a result | |||
==dbFree== | |||
<syntaxhighlight lang="lua"> | |||
dbFree( handle ) | |||
</syntaxhighlight> | |||
*'''dbFree''' makes a handle go away and never come back | |||
===Example usage of the above three functions:=== | |||
Perform a query such as UPDATE, without waiting for the result (super fast) | |||
<syntaxhighlight lang="lua">function dbQueryExec(...) | |||
local handle = dbQuery(...) | |||
dbFree(handle) | |||
end</syntaxhighlight> | |||
Perform a query such as SELECT, and wait for the result (super slow) | |||
<syntaxhighlight lang="lua">function dbQueryResult(...) | |||
local handle = dbQuery(...) | |||
return dbPoll(handle,-1) | |||
end</syntaxhighlight> | |||
Perform a query such as SELECT, and yield until the result is ready (avoids server stalling, but must be called in a coroutine) | |||
<syntaxhighlight lang="lua">function dbQueryLatent(...) | |||
local handle = dbQuery(...) | |||
local result | |||
do | |||
coroutine.yield() | |||
result = dbPoll(handle) | |||
until result ~= nil | |||
return result | |||
end</syntaxhighlight> | |||
== == | == == |
Revision as of 17:44, 22 October 2011
2011 October 22
How do you solve a problem like my server stalling?
Answer: coroutines and threaded database access
Propose 3 new database access functions:
dbQuery
handle dbQuery( sting query )
- dbQuery starts a database query and returns a handle
dbPoll
table dbPoll( handle[, int timeout = 0, bool autoFree = true ] )
- dbPoll returns the result of the query started with the supplied handle, or nil if the query has not completed yet. Setting timeout above 0 will make the function wait a bit longer if the query is not ready. A timeout of -1 will make it wait for ever. If autoFree is true, the query handle gets automatically freed when dbPoll is able to return a result
dbFree
dbFree( handle )
- dbFree makes a handle go away and never come back
Example usage of the above three functions:
Perform a query such as UPDATE, without waiting for the result (super fast)
function dbQueryExec(...) local handle = dbQuery(...) dbFree(handle) end
Perform a query such as SELECT, and wait for the result (super slow)
function dbQueryResult(...) local handle = dbQuery(...) return dbPoll(handle,-1) end
Perform a query such as SELECT, and yield until the result is ready (avoids server stalling, but must be called in a coroutine)
function dbQueryLatent(...) local handle = dbQuery(...) local result do coroutine.yield() result = dbPoll(handle) until result ~= nil return result end
2011 October 2
Master Plan 8012
Outline
To enhance MTA, keeps devs motivated and ensure stuff actually gets tested and used, I propose that features developed in the trunk be backported to the current version where possible.
Problem
However, when scripters start to use the new features, there will be compatibility problems with some servers & clients.
Solution
Therefore I present to you 'Master Plan 8012', which is:
- When a script is loaded into a server, its minimum version requirement is evaluated.
- If the script requires an updated server, it should not run and instead inform the server owner to update
- When the script is running, connecting clients below the script required minimum version are auto-updated
Benefits of this plan are:
- Scripters can use latest functions and not worry about checking version numbers and such
- Server owners can use any scripts without have to worry about setting <minclientversion> etc
- And more players will update because they will have a compelling reason to do so. (i.e. To join fav server)
Release dates
History
Version | Date | Highlights | User comments | |
1.0 | 22 August 2009 | First release | DP2 was better | |
1.0.1 | 02 October 2009 | Crash fixes and less lag | 1.0 was better | |
1.0.2 | 24 October 2009 | Crash fixes | 1.0.1 was better | |
1.0.3 | 17 December 2009 | Sync improved | 1.0.2 was better | |
1.0.4 (r1752) | 7 June 2010 | Security improved | 1.0.3 was better | |
1.0.4 (r1854) | 10 July 2010 | Crash fixes | It crashes more | |
1.0.4 (r2033) | 14 October 2010 | Crash fixes | It crashes more | |
1.0.4 (r2106) | 14 December 2010 | Browser improved | + | |
1.0.5 (r2488) | 27 March 2011 | AC improved | It crashes more & 1.0.4 was better | |
1.0.5 (r2519/2520) | 4 April 2011 | Performance fixed | 'It's almost as good as 1.0.2 now' | |
1.0.5 (r2560) | 16 April 2011 | Performance improvements | ||
1.1.0 | 25 August 2011 | Many new features | Possibly the worst thing that has happened in the history of the world | |
1.1.1 | 20 September 2011 | Accumulation of post release fixes | Lags more than 1.1 |