_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Creating C closures from Lua closures
not_a9 wrote 1 hour 29 min ago:
Fun fact: LuaJIT FFI actually has a similar feature. You can do funky
things like detour hooking with this functionality too.
HTML [1]: https://luajit.org/ext_ffi_semantics.html
halayli wrote 8 hours 39 min ago:
I feel libffi is better suited and supports most platforms.
rurban wrote 34 min ago:
The ffcall library even more
lkuty wrote 8 hours 10 min ago:
Tsoding made a video about it :
HTML [1]: https://www.youtube.com/watch?v=0o8Ex8mXigU
ufo wrote 9 hours 31 min ago:
I wonder if there would be a way to piggyback on top of GCC's nested
function extension. It does something a little bit similar, with the
dynamically generated functions.
shakna wrote 10 hours 2 min ago:
Why VirtualAlloc?
Lua has its own allocator, which will also collect for you.
lua_newuserdata. At the expense of having to set executable yourself,
but without all the inbuilt inefficiencies the article points out.
publicdebates wrote 8 hours 54 min ago:
Can you set arbitrary memory allocated by malloc (e.g. HeapAlloc in
Windows) to executable, via VirtualProtect or something else? If so,
that's news to me. I thought it had to be memory allocated by
VirtualAlloc only.
That said, I'm not sure that solution beats out this one. I'm using a
linked list on top of an arena allocator in practice, which means
allocations happen once every 0x10000 bytes. (A single C closure of
mine takes up exactly 16 bytes, which includes the pointer to the
next linked list node. I'm very happy with how it's designed.)
psychoslave wrote 10 hours 6 min ago:
Whatâs the thing emulating so much activity around closures lately?
[1] [2] Also talking about the Knuth boy/man test: [3] Not a bad thing,
but that really question if there is some active micro-
HTML [1]: https://news.ycombinator.com/item?id=46228597
HTML [2]: https://news.ycombinator.com/item?id=46259334
HTML [3]: https://news.ycombinator.com/item?id=46020151
widdershins wrote 13 hours 16 min ago:
This doesn't seem like something that should require generating
assembly to solve. Couldn't `CALLBACK` just return a table, which
contains both the userdata pointer to `REAL_CALLBACK` and a value for
`findex`, eliminating the global variable? Then `Add` could extract
that. You could even make the table returned by `CALLBACK` callable in
Lua with a metatable.
Or, if you're worried about performance/memory, you could allocate a
struct for `CALLBACK` to return as userdata, containing the function
pointer and `findex`. If you made a little allocator for these it would
be extremely fast.
I'm sure I'm missing things, but the solution you chose feels like the
nuclear option.
CodesInChaos wrote 10 hours 9 min ago:
Well designed C APIs have a context/userdata parameter on their
callbacks, which is registered and stored alongside the function
pointer. Unfortunately WNDPROC lacks this parameter.
GWLP_USERDATA should be the best option, though the API for setting
it and setting the WNDPROC being separate looks error prone.
publicdebates wrote 8 hours 57 min ago:
The bigger problem is that I would have to automate this for every
callback type in the Windows API, and there's no guarantee that all
of them follow the same 2 or 3 patterns for passing the context
pointer into the callback. This solution works great, even if it is
a bit wasteful of the ctx ptr.
comex wrote 12 hours 54 min ago:
The code is passing the function pointers into Win32 APIs, so the
caller side isnât controlled; the callbacks have to work as native
C function pointers.
This was probably posted in response to this other link from two days
ago, which is about about JIT-compiling wndproc callbacks in
particular; the comments discuss the âproperâ way to do it, which
is to use GWLP_USERDATA: [1] At least, thatâs the proper way to do
it if you control the entire application. But for whatâs
apparently a thin wrapper that exposes Win32 APIs directly to Lua, I
can understand picking an approach that makes life easier for the Lua
code author, even if itâs hackier under the hood. It also avoids
the need to write custom behavior for each API.
HTML [1]: https://news.ycombinator.com/item?id=46259334
publicdebates wrote 8 hours 59 min ago:
It was inspired by that post, but not in response to it. Over the 3
or 4 months that I took writing lowkPRO, one of the features I'm
most proud of is this, the ability for it to create C callbacks on
the fly that just call Lua callbacks and return the value to C. And
I would argue that it's not hacky but just well-engineered. After
all, everything compiles to assembly at the end of the day, right?
DIR <- back to front page