view util-src/managed_pointer.h @ 14066:b085d32af140 13.0

prosody, prosodyctl: Load loader directly from source directory This should ensure that loader.lua is loaded from the source directory and does the right thing when installed with `make install` There are currently three ways Prosody can be run: - Directly from the source directory, like `./prosody` - Installed with `make install` - Installed into Lua paths with e.g. dh-lua or luarocks In the first two cases, Lua search paths need to include the source directory and ensure that `require "prosody.util.json"` ends up loading `util/json.lua` relative to the installation (CFG_SOURCEDIR) or the source checkout. Finally, in the last case where Prosody resources are installed under the 'prosody.*' namespace in regular Lua search paths, then loader.lua should activate the compatibility mode that makes sure that both `require"util.json"` and `require"prosody.util.json"` both resolve to `(one path from of package.path)/prosody/util/json.lua`
author Kim Alvefur <zash@zash.se>
date Mon, 09 Feb 2026 16:59:42 +0100
parents b001b0f42512
children
line wrap: on
line source

/* managed_pointer.h

These macros allow wrapping an allocator/deallocator into an object that is
owned and managed by the Lua garbage collector.

Why? It is too easy to leak objects that need to be manually released, especially
when dealing with the Lua API which can throw errors from many operations.

USAGE
-----

For example, given an object that can be created or released with the following
functions:

  fancy_buffer* new_buffer();
  void free_buffer(fancy_buffer* p_buffer)

You could declare a managed version like so:

  MANAGED_POINTER_ALLOCATOR(new_managed_buffer, fancy_buffer*, new_buffer, free_buffer)

And then, when you need to create a new fancy_buffer in your code:

  fancy_buffer *my_buffer = new_managed_buffer(L);

NOTES
-----

Managed objects MUST NOT be freed manually. They will automatically be
freed during the next GC sweep after your function exits (even if via an error).

The managed object is pushed onto the stack, but should generally be ignored,
but you'll need to bear this in mind when creating managed pointers in the
middle of a sequence of stack operations.
*/

#define MANAGED_POINTER_MT(wrapped_type) #wrapped_type "_managedptr_mt"

#define MANAGED_POINTER_ALLOCATOR(name, wrapped_type, wrapped_alloc, wrapped_free) \
  static int _release_ ## name(lua_State *L) {                                \
  	wrapped_type *p = (wrapped_type*)lua_topointer(L, 1);                 \
  	if(*p != NULL) {                                                      \
	  	wrapped_free(*p);                                             \
	}                                                                     \
  	return 0;                                                             \
  }                                                                           \
  static wrapped_type name(lua_State *L) {                                    \
  	wrapped_type *p = (wrapped_type*)lua_newuserdata(L, sizeof(wrapped_type)); \
  	if(luaL_newmetatable(L, MANAGED_POINTER_MT(wrapped_type)) != 0) {     \
  		lua_pushcfunction(L, _release_ ## name);                      \
  		lua_setfield(L, -2, "__gc");                                  \
  	}                                                                     \
  	lua_setmetatable(L, -2);                                              \
  	*p = wrapped_alloc();                                                 \
  	if(*p == NULL) {                                                      \
  		lua_pushliteral(L, "not enough memory");                      \
  		lua_error(L);                                                 \
  	}                                                                     \
  	return *p;                                                            \
  }