Re: How to comprehend that Lua automatically removes whatever is in the stack below the results after the function returned?

[孙世龙 sunshilong <sunshilong369@...>]

>However, the data processed in every cycle has a more or less constant,
>and limited size. There is no handling of "lengthy" (thousands of bytes)
>strings.
If I understand correctly, all the objects should have a pre-known max
size to meet the soft real-time requirements.

>If you have something completely different in mind, all my suggestions
>above may not be helpful at all - so probably you should explain a little
>more on your use case (I don't want to bother you with irrelevant stuff).
I use Lua scripts to control the robot arm to grab cookies, plates, fruits
and etc. And move them from one point to another.
No damage or bad things may happen if the soft real-time requirement is
breaked occasionally.

Best regards.
Sunshilong



On Fri, Sep 25, 2020 at 5:57 AM bel <bel2125@gmail.com> wrote:
>
> Yes, all objects (strings, tables/arrays, ...) need to have a known maximum size. But that's by no means specific to Lua.
> There are a lot of implicit assumptions on the type of real time system in my two short comments above - that's why I finally asked for some information on the kind of real time system you have in mind, because maybe all my attempts to explain could be a waste of time for both of us, if you have completely different requirements than I had and you are looking for something completely different.
>
> By "real time" I mean some loop running in some fixed cycle (somewhere between 100 microseconds and 10 milliseconds) or event/interrupt driven. Every cycle starts with reading some input values (booleans and numbers) corresponding to sensor signals. Inputs could also be "messages" (data from serial communication, network packages, ...) - these are of type string but with a well known maximum length (the serial interface has a maximum baud rate, you know the cycle time --> you can calculate it). Within every cycle you need to process all (relevant) inputs, e.g. by filtering it and storing results in a log (data logger), by calculating outputs (closed loop control), probably updating some internal state machines, ... In any case, you must never miss any cycle, because the input data will be gone, the data logs incomplete, the outputs and state machines incorrect. However, the data processed in every cycle has a more or less constant, and limited size. There is no handling of "lengthy" (thousands of bytes) strings.
> If you have something completely different in mind, all my suggestions above may not be helpful at all - so probably you should explain a little more on your use case (I don't want to bother you with irrelevant stuff).
>
> On Thu, Sep 24, 2020 at 3:34 PM Gé Weijers <ge@weijers.org> wrote:
>>
>>
>>
>> On Wed, Sep 23, 2020, 11:56 bel <bel2125@gmail.com> wrote:
>>>
>>> > Growing an object requires copying, which can't be done in constant time. Most CPUs can copy very quickly but it's still an O(n) operation, however efficient you make the memory management.
>>>
>>> Even copying is only O(n) for a "larger" number of bytes n. For small n effects memory access, caching, ... (random effects) do have a much bigger effect on execution time than copying a byte more - making it effectively independent from n. The ~32 bytes mentioned before would be "small" from that point of view.
>>
>>
>> Growing a table is the operation that would cause significant delays when the table is large enough. You would have to keep sizes small or fixed to guarantee constant time operations.
>>
>> Growing an array by doubling it's size when you run out of space has O(1) complexity, but that is amortized complexity which is not good enough for hard realtime work unless you limit the maximum array size.
>>
>>>