cPluginManager:GetLuaPlugin() and lua_State

[ThuGie]

Seems quite complicated to solve it,
As i asume people who create plugins would want all the access they can get.

[FakeTruth]

Look at this incredibly handsome diagram.
Yellow arrow means indirect/non-blocking communication by using queues.
Red arrow means direct/blocking communication.


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.

[FakeTruth]

Nobody has any thoughts about this? :O

[xoft]

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

[FakeTruth]

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.

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

Aww man.. I spent like an hour drawing that diagram with my pro photoshop skillz