Andreas/evennia
1
0
Fork 0
mirror of https://github.com/evennia/evennia.git synced 2026-04-03 14:37:17 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Updating ReST docs.

Browse source
This commit is contained in:
Griatch 2012-03-15 15:26:07 +01:00
parent f46a9a1280
commit 2eb5c4fc8c
39 changed files with 410 additions and 1203 deletions
Download patch file Download diff file Expand all files Collapse all files

45
docs/sphinx/source/wiki/AsyncProcess.rst
View file

@ -17,9 +17,7 @@ Consider this piece of code:
::
print "before call ..."
long_running_function()
print "after call ..."
print "before call ..." long_running_function() print "after call ..."
When run, this will print ``"before call ..."``, after which the
``long_running_function`` gets to work for however long time. Only once
@ -45,10 +43,7 @@ use of the ``run_async()`` function in ``src/utils/utils.py``.
::
from src.utils import utils
print "before call ..."
utils.run_async(long_running_function)
print "after call ..."
from src.utils import utils print "before call ..." utils.run_async(long_running_function) print "after call ..."
Now, when running this you will find that the program will not wait
around for ``long_running_function`` to finish. Infact you will see
@ -79,8 +74,7 @@ called automatically.
::
def at_return(r):
print r
def at_return(r): print r
- ``at_err(e)`` (the *errback*) is called if the asynchronous function
fails and raises an exception. This exception is passed to the
@ -99,19 +93,7 @@ An example of making an asynchronous call from inside a
::
from src.utils import utils
from game.gamesrc.commands.basecommand import Command
class CmdAsync(Command): key = "asynccommand" def func(self):
def long_running_function():
#[... lots of time-consuming code
return final_value
def at_return(r):
self.caller.msg("The final value is %s" % r) def at_err(e):
self.caller.msg("There was an error: %s" % e) # do the async call, setting all callbacks
utils.run_async(long_running_function, at_return, at_err)
from src.utils import utils from game.gamesrc.commands.basecommand import Command class CmdAsync(Command): key = "asynccommand" def func(self): def long_running_function(): #[... lots of time-consuming code return final_value def at_return(r): self.caller.msg("The final value is %s" % r) def at_err(e): self.caller.msg("There was an error: %s" % e) # do the async call, setting all callbacks utils.run_async(long_running_function, at_return, at_err)
That's it - from here on we can forget about ``long_running_function``
and go on with what else need to be done. *Whenever* it finishes, the
@ -121,12 +103,19 @@ for us to see. If not we will see an error message.
Assorted notes
--------------
Be careful with choosing when to use asynchronous calls. It is mainly
useful for large administration operations that has no direct influence
on the game world (imports and backup operations come to mind). Since
there is no telling exactly when an asynchronous call actually ends,
using them for in-game commands is to potentially invite confusion and
inconsistencies (and very hard-to-reproduce bugs).
Note that the ``run_async`` will try to launch a separate thread behind
the scenes. Some databases, notably our default database SQLite3, does
*not* allow concurrent read/writes. So if you do a lot of database
access (like saving to an Attribute) in your function, your code might
actually run *slower* using this functionality if you are not careful.
Extensive real-world testing is your friend here.
Overall, be careful with choosing when to use asynchronous calls. It is
mainly useful for large administration operations that has no direct
influence on the game world (imports and backup operations come to
mind). Since there is no telling exactly when an asynchronous call
actually ends, using them for in-game commands is to potentially invite
confusion and inconsistencies (and very hard-to-reproduce bugs).
The very first synchronous example above is not *really* correct in the
case of Twisted, which is inherently an asynchronous server. Notably you