Re: Delay garbage collection of some data possible? ("validate" data for C?)

[Flyer31 Test <flyer31@...>]

Thank you for info - this confirms what I also thought after reading the Email of Xmilia, thank you for this input Xmilia, this was interesting paragraph in the reference manual.

So for now I think I really best just stop the garbage collector with collectgarbage("stop") when I start the DMA, and then I will restart/continue it after the DMA stopped by collectgarbage( "restart").

I did not invoke Lua functions so far directly from my C code, but I think this I should "get boken" without problems.. .

Thank you for your input Philippe, but if I understand you correctly, this would somehow imply some yielding in the Lua user program, or "cutting" the large buffer sending into smaller packages in the Lua user program, but this I definitely want to avoid - I know that a percentage of our users will be for sure by too lazy / too stupid for this... .

The function which my c code presents to the Lua user should really have some very easy form, e. g. like

myComWriteDelay( str, mode)

And if the user then selects the mode "wait", my c code has to be smart enough to wait by yielding. And if the user prefers to select "no wait" mode, then the lua program should just continue, but the DMA must continue to run in the background ... . Of course the DMA must be finished before the next invocation of myComWriteDelay function... this then my C code will check and on error will shut down the user Lua thread with some "nice error message".

On Fri, Jun 11, 2021 at 3:18 PM Edoardo <edoardo762@gmail.com> wrote:

Yes, that's how you would ref/unref in the registry index, tho as Xmilia pointed
out to me in their mail, this would only make sure the string is still
accessible
as lua object but doesn't guarantee that the char* pointer returned by
the string
will remain valid once the stack is popped for the function to return.
So my solution
would only work if you still want to keep that string alive in the lua
vm, not the char*
pointer valid in the program. (So only half of your issue will get solved.)

2021-06-11 13:45 GMT+02:00, Flyer31 Test <flyer31@googlemail.com>:
> Thank you for answer, this sounds interesting, but unfortunately I never
> used luaL_ref before and I would prefer some short 2-3 lines example if
> possible.
>
> Currently when I get my String I would use (L is my lua_State*)
> const char* pcData= lua_tostring( L, -1);
> (so the string would be on top of stack...)
>
> So you instead would propose to use
> const int iRefData= luaL_ref ( L, LUA_REGISTRYINDEX);
>
> ... and how would I then get the pcData? The RefMan under luaL_ref seems to
> sugget somehow "lua_rawgeti( L, LUA_REGISTRYINDEX, iRefData)" ... but I
> must admit I have no glue how to come to pcData from this ... ? Possibly
> like the following two lines:
>
> const int iRefData= luaL_ref ( L, LUA_REGISTRYINDEX);
> lua_rawgeti( L, LUA_REGISTRYINDEX, iRefData);
> const char* pcData= lua_tostring( L, -1);
>
> ...  and when I do not need any more the data, then ...
>
>
> luaL_unref(L, LUA_REGISTRYINDEX, iRefData);
>
> Could you check / correct / confirm this?
>
>
> On Fri, Jun 11, 2021 at 10:58 AM Edoardo <edoardo762@gmail.com> wrote:
>
>> You could hold a reference to this value in the registry index:
>> luaL_ref(current_state, LUA_REGISTRYINDEX);
>> In this way, there will always ne a reference to ut until you manaully
>> remove the entry from the registry, thus the Garbage Collector won't
>> collect it
>> On 11 Jun 2021, at 10:47, Flyer31 Test <flyer31@googlemail.com> wrote:
>>>
>>> In my Lua microcontroller application (quite restricted RAM space), I
>>> would implement some function written by C, which sends data out through
>>> a
>>> serial interface.
>>>
>>> So this function gets e. g. a longer string (e. g. 200-1000 bytes), and
>>> sends out through serial interface.
>>>
>>> For doing this in an optimum way, I would use DMA (Direct Memory
>>> access),
>>> tell the DMA the start address of this string data, and then continue
>>> with
>>> my Lua program (or if the user prefers to wait end of send, I would call
>>> yieldk/resume and thus do some other CPU work until the DMA send has
>>> finished).
>>>
>>> Problem now is, that as soon that I leave my c function with yieldk,
>>> principally the Lua garbage collector could free this string, as it will
>>> not be needed any more by Lua.
>>>
>>> Is there some simple and elegant way to tell to avoid this?
>>>
>>> (of course I could also allocate some memory by c, and then copy the
>>> string to this allocated memory... but this sounds a bit weird for me as
>>> I
>>> am used to program such microcontroller application always in a very
>>> time-
>>> and RAM-optimized way - further I want to restrict the dynamic memory
>>> allocation exclusively to Lua - for "usual microcontroller" programming
>>> I
>>> would not use any dynamic memory allocation at all ... therefore it
>>> would
>>> be great if for the typical send time of some msec (could also be
>>> 200msec...) Lua garbage collector could somehow be "informed" that this
>>> string still is "in use")
>>>
>>> (or should I better disable the Lua garbage collector during this time
>>> ... but this would sound also a bit weird to me, as it could me, that
>>> during some "file transfer" this sending will occur for longer time, and
>>> I
>>> would not like to block the lua garbage collector for "longer time").
>>>
>>> ... but for DMA it is important, that the Lua Garbage collector for sure
>>> NEITHER will free this string, NOR will re-allocate this string to some
>>> other place, until my C code signifies to Lua that the send is finished
>>> /
>>> the data is not used any more.
>>>
>>>
>