From dbd925a7a4a2ce947bc3397e8633c56377657b88 Mon Sep 17 00:00:00 2001 From: madmaxoft Date: Wed, 16 Oct 2013 08:04:06 +0200 Subject: APIDump: Nicer HTML visage. * Fixed whacky HTML indentation + Added fancy CSS! + Now HTML5 compatible! --- MCServer/Plugins/APIDump/WebWorldThreads.html | 116 ++++++------ MCServer/Plugins/APIDump/main.css | 30 +++- MCServer/Plugins/APIDump/main.lua | 242 +++++++++++++++----------- 3 files changed, 230 insertions(+), 158 deletions(-) (limited to 'MCServer/Plugins') diff --git a/MCServer/Plugins/APIDump/WebWorldThreads.html b/MCServer/Plugins/APIDump/WebWorldThreads.html index a77209b0b..7cc94e9fa 100644 --- a/MCServer/Plugins/APIDump/WebWorldThreads.html +++ b/MCServer/Plugins/APIDump/WebWorldThreads.html @@ -1,64 +1,64 @@ + - -MCServer - Webserver vs World threads - - - - + + MCServer - Webserver vs World threads + + + + +

Webserver vs World threads

+

+ This article will explain the threading issues that arise between the webserver and world threads are of concern to plugin authors.

+

+ Generally, plugins that provide webadmin pages should be quite careful about their interactions. Most operations on MCServer objects requires synchronization, that MCServer provides automatically and transparently to plugins - when a block is written, the chunkmap is locked, or when an entity is being manipulated, the entity list is locked. Each plugin also has a mutex lock, so that only one thread at a time may be executing plugin code.

+

+ This locking can be a source of deadlocks for plugins that are not written carefully.

-

Webserver vs World threads

-

-This article will explain the threading issues that arise between the webserver and world threads are of concern to plugin authors.

-

-Generally, plugins that provide webadmin pages should be quite careful about their interactions. Most operations on MCServer objects requires synchronization, that MCServer provides automatically and transparently to plugins - when a block is written, the chunkmap is locked, or when an entity is being manipulated, the entity list is locked. Each plugin also has a mutex lock, so that only one thread at a time may be executing plugin code.

-

-This locking can be a source of deadlocks for plugins that are not written carefully.

+

Example scenario

+

Consider the following example. A plugin provides a webadmin page that allows the admin to kick players off the server. When the admin presses the "Kick" button, the plugin calls cWorld:DoWithPlayer() with a callback to kick the player. Everything seems to be working fine now.

+

+ A new feature is developed in the plugin, now the plugin adds a new in-game command so that the admins can kick players while they're playing the game. The plugin registers a command callback with cPluginManager.AddCommand(). Now there are problems bound to happen.

+

+ Suppose that two admins are in, one is using the webadmin and the other is in-game. Both try to kick a player at the same time. The webadmin locks the plugin, so that it can execute the plugin code, but right at this moment the OS switches threads. The world thread locks the world so that it can access the list of in-game commands, receives the in-game command, it tries to lock the plugin. The plugin is already locked, so the world thread is put on hold. After a while, the webadmin thread is woken up again and continues processing. It tries to lock the world so that it can traverse the playerlist, but the lock is already held by the world thread. Now both threads are holding one lock each and trying to grab the other lock, and are therefore deadlocked.

-

Example scenario

-

Consider the following example. A plugin provides a webadmin page that allows the admin to kick players off the server. When the admin presses the "Kick" button, the plugin calls cWorld:DoWithPlayer() with a callback to kick the player. Everything seems to be working fine now.

-

-A new feature is developed in the plugin, now the plugin adds a new in-game command so that the admins can kick players while they're playing the game. The plugin registers a command callback with cPluginManager.AddCommand(). Now there are problems bound to happen.

-

-Suppose that two admins are in, one is using the webadmin and the other is in-game. Both try to kick a player at the same time. The webadmin locks the plugin, so that it can execute the plugin code, but right at this moment the OS switches threads. The world thread locks the world so that it can access the list of in-game commands, receives the in-game command, it tries to lock the plugin. The plugin is already locked, so the world thread is put on hold. After a while, the webadmin thread is woken up again and continues processing. It tries to lock the world so that it can traverse the playerlist, but the lock is already held by the world thread. Now both threads are holding one lock each and trying to grab the other lock, and are therefore deadlocked.

+

How to avoid the deadlock

+

+ There are two main ways to avoid such a deadlock. The first approach is using tasks: Everytime you need to execute a task inside a world, instead of executing it, queue it, using cWorld:QueueTask(). This handy utility can will call the given function inside the world's TickThread, thus eliminating the deadlock, because now there's only one thread. However, this approach will not let you get data back. You cannot query the player list, or the entities, or anything - because when the task runs, the webadmin page has already been served to the browser.

+

+ To accommodate this, you'll need to use the second approach - preparing and caching data in the tick thread, possibly using callbacks. This means that the plugin will have global variables that will store the data, and update those variables when the data changes; then the webserver thread will only read those variables, instead of calling the world functions. For example, if a webpage was to display the list of currently connected players, the plugin should maintain a global variable, g_WorldPlayers, which would be a table of worlds, each item being a list of currently connected players. The webadmin handler would read this variable and create the page from it; the plugin would use HOOK_PLAYER_JOINED and HOOK_DISCONNECT to update the variable.

-

How to avoid the deadlock

-

-There are two main ways to avoid such a deadlock. The first approach is using tasks: Everytime you need to execute a task inside a world, instead of executing it, queue it, using cWorld:QueueTask(). This handy utility can will call the given function inside the world's TickThread, thus eliminating the deadlock, because now there's only one thread. However, this approach will not let you get data back. You cannot query the player list, or the entities, or anything - because when the task runs, the webadmin page has already been served to the browser.

-

-To accommodate this, you'll need to use the second approach - preparing and caching data in the tick thread, possibly using callbacks. This means that the plugin will have global variables that will store the data, and update those variables when the data changes; then the webserver thread will only read those variables, instead of calling the world functions. For example, if a webpage was to display the list of currently connected players, the plugin should maintain a global variable, g_WorldPlayers, which would be a table of worlds, each item being a list of currently connected players. The webadmin handler would read this variable and create the page from it; the plugin would use HOOK_PLAYER_JOINED and HOOK_DISCONNECT to update the variable.

+

What to avoid

+

+ Now that we know what the danger is and how to avoid it, how do we know if our code is susceptible?

+

+ The general rule of thumb is to avoid calling any functions that read or write lists of things in the webserver thread. This means most ForEach() and DoWith() functions. Only cRoot:ForEachWorld() is safe - because the list of worlds is not expected to change, so it is not guarded by a mutex. Getting and setting world's blocks is, naturally, unsafe, as is calling other plugins, or creating entities.

-

What to avoid

-

-Now that we know what the danger is and how to avoid it, how do we know if our code is susceptible?

-

-The general rule of thumb is to avoid calling any functions that read or write lists of things in the webserver thread. This means most ForEach() and DoWith() functions. Only cRoot:ForEachWorld() is safe - because the list of worlds is not expected to change, so it is not guarded by a mutex. Getting and setting world's blocks is, naturally, unsafe, as is calling other plugins, or creating entities.

- -

Example

-The Core has the facility to kick players using the web interface. It used the following code for the kicking (inside the webadmin handler): -
-local KickPlayerName = Request.Params["players-kick"]
-local FoundPlayerCallback = function(Player)
-  if (Player:GetName() == KickPlayerName) then
-    Player:GetClientHandle():Kick("You were kicked from the game!")
-  end
-end
-cRoot:Get():FindAndDoWithPlayer(KickPlayerName, FoundPlayerCallback)
-
-The cRoot:FindAndDoWithPlayer() is unsafe and could have caused a deadlock. The new solution is queue a task; but since we don't know in which world the player is, we need to queue the task to all worlds: -
-cRoot:Get():ForEachWorld(    -- For each world...
-  function(World)
-    World:QueueTask(         -- ... queue a task...
-      function(a_World)
-        a_World:DoWithPlayer(KickPlayerName,  -- ... to walk the playerlist...
-          function (a_Player)
-            a_Player:GetClientHandle():Kick("You were kicked from the game!")  -- ... and kick the player
-          end
-        )
-      end
-    )
-  end
-)
-
- +

Example

+ The Core has the facility to kick players using the web interface. It used the following code for the kicking (inside the webadmin handler): + 
+		local KickPlayerName = Request.Params["players-kick"]
+		local FoundPlayerCallback = function(Player)
+		  if (Player:GetName() == KickPlayerName) then
+			Player:GetClientHandle():Kick("You were kicked from the game!")
+		  end
+		end
+		cRoot:Get():FindAndDoWithPlayer(KickPlayerName, FoundPlayerCallback)
+
+ The cRoot:FindAndDoWithPlayer() is unsafe and could have caused a deadlock. The new solution is queue a task; but since we don't know in which world the player is, we need to queue the task to all worlds: + 
+		cRoot:Get():ForEachWorld(    -- For each world...
+		  function(World)
+			World:QueueTask(         -- ... queue a task...
+			  function(a_World)
+				a_World:DoWithPlayer(KickPlayerName,  -- ... to walk the playerlist...
+				  function (a_Player)
+					a_Player:GetClientHandle():Kick("You were kicked from the game!")  -- ... and kick the player
+				  end
+				)
+			  end
+			)
+		  end
+		)
+
+ \ No newline at end of file diff --git a/MCServer/Plugins/APIDump/main.css b/MCServer/Plugins/APIDump/main.css index 777f6d71a..5cc603a3f 100644 --- a/MCServer/Plugins/APIDump/main.css +++ b/MCServer/Plugins/APIDump/main.css @@ -1,3 +1,8 @@ +html +{ + background-color: #C0C0C0; +} + table { background-color: #fff; @@ -25,4 +30,27 @@ pre { border: 1px solid #ccc; background-color: #eee; -} \ No newline at end of file +} + +body +{ + min-width: 800px; + width: 95%; + margin: 10px auto; + background-color: white; + border: 4px #FF8C00 solid; + border-radius: 20px; + font-family: Calibri, Trebuchet MS; +} + +header +{ + text-align: center; + font-family: Segoe UI Light, Helvetica; +} + +#content +{ + padding: 0px 25px 25px 25px; +} + diff --git a/MCServer/Plugins/APIDump/main.lua b/MCServer/Plugins/APIDump/main.lua index 163c505b2..22801b1e5 100644 --- a/MCServer/Plugins/APIDump/main.lua +++ b/MCServer/Plugins/APIDump/main.lua @@ -22,7 +22,7 @@ function Initialize(Plugin) Plugin:SetName("APIDump"); Plugin:SetVersion(1); - LOG("Initialized " .. Plugin:GetName() .. " v." .. Plugin:GetVersion()) + LOG("Initialised " .. Plugin:GetName() .. " v." .. Plugin:GetVersion()) g_PluginFolder = Plugin:GetLocalFolder(); @@ -212,48 +212,69 @@ function DumpAPIHtml() return; end - f:write([[MCServer API - index - -

MCServer API - index

-

The API reference is divided into the following sections:

-

Class index

 -

The following classes are available in the MCServer Lua scripting language: -