cPluginManager:GetLuaPlugin() and lua_State
#21
Seems quite complicated to solve it,
As i asume people who create plugins would want all the access they can get.
MCServer: infinity.thugie.nl:25566 - Online when possible, not when crashed or updating lol.
Reply
Thanks given by:
#22
Look at this incredibly handsome diagram.
Yellow arrow means indirect/non-blocking communication by using queues.
Red arrow means direct/blocking communication.
[Image: 1oxc1c.png]

I don't know if it is clear to you, but it shows what is looks like when all game mechanics are handled in the tick thread (as it should IMO) and the other threads are isolated, only able to communicate in a non-blocking way.
Reply
Thanks given by:
#23
Nobody has any thoughts about this? :O
Reply
Thanks given by:
#24
It'd be quite difficult and uselessly complicated to decouple the chunk generator from the plugins in order to use non-blocking queues. I'd say that would be impractical, since a "collision" there is highly improbable - chunk generation-altering plugins are very unlikely to interact with anything else than the generator itself.

The problem with your diagram is that it's too simplified. The arrow from Plugins to Packet handling thread actually goes through other threads and is kinda blocking. Also, there can be multiple packet handling threads (one thread can handle only 63 clients - cSocketThreads limit due to select() OS call limit).

I honestly don't think this is worth "solving" now. Things do work now, let's be an agile team and solve things only when they are actually needed Wink
Reply
Thanks given by:
#25
(09-29-2012, 11:44 PM)xoft Wrote: It'd be quite difficult and uselessly complicated to decouple the chunk generator from the plugins in order to use non-blocking queues. I'd say that would be impractical, since a "collision" there is highly improbable - chunk generation-altering plugins are very unlikely to interact with anything else than the generator itself.
In my diagram it's not decoupled, it's a red arrow which means it can call functions directly.

(09-29-2012, 11:44 PM)xoft Wrote: The problem with your diagram is that it's too simplified. The arrow from Plugins to Packet handling thread actually goes through other threads and is kinda blocking. Also, there can be multiple packet handling threads (one thread can handle only 63 clients - cSocketThreads limit due to select() OS call limit).

I honestly don't think this is worth "solving" now. Things do work now, let's be an agile team and solve things only when they are actually needed Wink
Aww man.. I spent like an hour drawing that diagram with my pro photoshop skillz
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)