module is not reloadable

[olegrok]

tarantool> require('tuple.keydef')
---
- merge: 'function: 0x0f473d18'
  extract_key: 'function: 0x0f473c70'
  new: 'function: 0x0f473c38'
  totable: 'function: 0x0f473d50'
  compare_with_key: 'function: 0x0f473ce0'
  compare: 'function: 0x0f473ca8'
...

tarantool> package.loaded['tuple.keydef'] = nil
---
...

tarantool> require('tuple.keydef')
---
- error: 'tuple.keydef/postload.lua:14: cannot change a protected metatable'
...

[Totktonada]

We implemented a naive implementation, which works good for reloading the module without updating. It will be released in the 0.0.2 version of the module.

The key problem of this implementation is that we set a metatable for keydef objects once and will not update its methods at reload.

I think that we can capture a methods table from __index and update this table at reloading with the new methods. It'll update behaviour as for old as well as for new keydef objects. If we'll need to keep the behaviour of existing keydef objects, we should maintain versioned struct tuple_keydef ctypes (struct tuple_keydef_v1, struct tuple_keydef_v2 and so on) and the corresponding set of method tables.

While there are no near plans to change behaviour of existing methods and/or to add new methods, I'll leave it as is.

[Totktonada]

@rosik reminded me another important problem with reloading of Lua/C modules. LuaJIT loads .so / .dylib module using dlopen(), which may be smart enough to understand that we trying to load the same library and don't actually re-read the file. So, we cannot guarantee that the new version of the library will be loaded after package.loaded.foo = nil and require('foo').

I'm not sure, but I guess that we cannot guarantee the opposite too. Whether tarantool will do dlclose() for a Lua/C module? If so, whether that fact that dlclose() is called strictly before the new dlopen(), guarantee that the library will be re-read (even if neither filename not inode was changed)?

So, in fact, the maximum that we can do now from a Lua/C module side is just successfully pass the reloading scenario and don't give any guarantees, whether the old or the new behaviour will be in effect after the reload.