Persistent objects
#1
If I were to ask, "what is the single most unintuitive thing in MCS plugin development", I'm pretty sure most of the answers would be "DoWithXYZ callbacks". The dreaded Lua object lifetime problem, when the Lua object is valid, but the underlying C++ object may have gone missing already.

Now what if I told you it doesn't have to be this way. Have a look at the cNetwork API - it doesn't suffer this issue, although the conditions are the same - the connection may go away at any point, the remote peer can disconnect at any time, yet it's perfectly valid to keep the cTCPLink objects in Lua and call operations on them long after that. Have you even noticed this little "revolution"? Smile

The way to do this is a bit of black magic - all such objects need to be represented as SharedPtrs and they need to take and release ownership of themselves at certain times. But it can be done.
One problem though - it means writing an awful lot of glue code. ToLua cannot generate bindings for these, it all needs to be hand-written. And it would need rewriting almost everything in the server, instead of passing raw pointers around to passing SharedPtrs around. But it can be done.

The question now is: how much determined are we to make a change? Are we? Or is the status quo good enough so that we needn't bother?
Reply
Thanks given by: sphinxc0re


Messages In This Thread
Persistent objects - by xoft - 04-13-2015, 01:12 AM
RE: Persistent objects - by NiLSPACE - 04-13-2015, 02:10 AM
RE: Persistent objects - by FakeTruth - 04-13-2015, 06:10 AM
RE: Persistent objects - by xoft - 04-13-2015, 07:46 AM
RE: Persistent objects - by worktycho - 04-15-2015, 09:40 AM
RE: Persistent objects - by worktycho - 04-15-2015, 10:11 PM
RE: Persistent objects - by worktycho - 05-01-2015, 12:00 AM



Users browsing this thread: 2 Guest(s)