The new version of 'lua_sethook' (not yet released :-) has the
following explanation:
/*
** This function can be called asynchronous (e.g. during a signal).
** Fields 'oldpc', 'basehookcount', and 'hookcount' (set by
** 'resethookcount') are for debug only, and it is no problem if they
** get arbitrary values (causes at most one wrong hook call). 'hookmask'
** is an atomic value. We assume that pointers are atomic too (e.g., gcc
** ensures that for all platforms where it runs). Moreover, 'hook' is
** always checked before being called (see 'luaD_hook').
*/
So, if by "truly portable" you mean we can prove it is correct following
the ANSI C documentation (which is our usual meaning, too), then you
are right. But if we assume that "truly portable" means it will run
correctly in any existing machine, than I guess that function is OK.
A further problem when having to "break into" running Lua code is that lua_sethook() seems to apply only to the specified Lua thread (coroutine). At the very least, the current documentation does not seem to mention whether hooks are per-thread or otherwise, so this is safest to assume (for the purpose of "breaking in") and it is most versatile for general needs, too. However, this makes it more difficult for the hosting application to implement the "break in" functionality, if it has to assume that coroutines might be used, and especially if it has to assume that that coroutines might be created via the C-level API. One could use a custom memory allocator, which keeps track of all the Lua threads for a given Lua state, and then setting the hook in all the known Lua threads, but that, even though it works, does not look like a very simple solution.
The question is, is there a simpler way?
Cheers,
V.
