Left here for archival purposes.

User avatar
By cal
#14841
TerryE wrote:Just remember to make everything local and even though an event has fired the reference to it is still in the handlers table, preventing GC, so doing an s:on("connection", nil) in update_factory() will dereference itself allowing GC, etc.


Moin Terry,

are you sure on this? I was under the impression that net_delete (the destructor) does free the connection ref
luaL_unref(L, LUA_REGISTRYINDEX, nud->cb_connect_ref);
on s:close and that this is even a problem because the registered disconnect handler may access freed memory.

Carsten
User avatar
By TerryE
#14845
raz123 wrote:You're possibly trying to concatenate a nil variable. As a test, try replacing:..

How about:
Code: Select all> for i,v in ipairs ({1,3,nil, 4}) do print (i,v) end
1   1
2   3

ipairs() stops at the first nil value so neither i nor v will be nil. Yes, you need to be aware of the possibility of nil values in some cases but not this one.
User avatar
By TerryE
#14846
cal wrote:are you sure on this? I was under the impression that net_delete (the destructor) does free the connection ref
luaL_unref(L, LUA_REGISTRYINDEX, nud->cb_connect_ref);
on s:close and that this is even a problem because the registered disconnect handler may access freed memory.


Carsten, you might be right in the case of this DTOR, but I came across this issue with tmr alarms where setting the value to nil does free up extra memory.