Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?

孙世龙 sunshilong
Hi, list

Since the input argument named osize has not been used in the
l_alloc() function, why still pass LUA_TTHREAD to this function in
lua_newstate()?
For your convenience, the related code snippets are seen at the footnotes.
Thank you for your attention to this matter.

Here are the related code snippets:

static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
  (void)ud; (void)osize;  /* not used */
  if (nsize == 0) {
    free(ptr);
    return NULL;
  }
  else
    return realloc(ptr, nsize);
}


LUA_API lua_State *lua_newstate (lua_Alloc f, void *ud) {
  int i;
  lua_State *L;
  global_State *g;
  LG *l = cast(LG *, (*f)(ud, NULL, LUA_TTHREAD, sizeof(LG)));
  if (l == NULL) return NULL;
...
}

Best Regards.
Sunshilong
Reply | Threaded
Open this post in threaded view
|

Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?

云风 Cloud Wu
孙世龙 sunshilong <[hidden email]> 于2020年8月13日周四 上午11:21写道:
>
> Hi, list
>
> Since the input argument named osize has not been used in the
> l_alloc() function, why still pass LUA_TTHREAD to this function in
> lua_newstate()?

RTFM : http://www.lua.org/manual/5.4/manual.html#lua_Alloc

When ptr is NULL, osize encodes the kind of object that Lua is
allocating. osize is any of LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
LUA_TUSERDATA, or LUA_TTHREAD when (and only when) Lua is creating a
new object of that type. When osize is some other value, Lua is
allocating memory for something else.
Reply | Threaded
Open this post in threaded view
|

Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?

孙世龙 sunshilong
Thank you for taking the time to respond to my question.

>osize is any of LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
>LUA_TUSERDATA, or LUA_TTHREAD when (and only when) Lua is creating a
>new object of that type. When osize is some other value, Lua is
>allocating memory for something else.

I see.
Osize has not been used in the l_alloc() function.
So I think it's no meaning to pass such arguments(i.e. LUA_TSTRING,
LUA_TTABLE, LUA_TFUNCTION) to it.
Am I missing something?

Here is the related code snippet for default memory management function for Lua:
static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
  (void)ud; (void)osize;  /* not used */
...
}

Thank you for your attention to this matter.

On Thu, Aug 13, 2020 at 11:35 AM 云风 Cloud Wu <[hidden email]> wrote:

>
> 孙世龙 sunshilong <[hidden email]> 于2020年8月13日周四 上午11:21写道:
> >
> > Hi, list
> >
> > Since the input argument named osize has not been used in the
> > l_alloc() function, why still pass LUA_TTHREAD to this function in
> > lua_newstate()?
>
> RTFM : http://www.lua.org/manual/5.4/manual.html#lua_Alloc
>
> When ptr is NULL, osize encodes the kind of object that Lua is
> allocating. osize is any of LUA_TSTRING, LUA_TTABLE, LUA_TFUNCTION,
> LUA_TUSERDATA, or LUA_TTHREAD when (and only when) Lua is creating a
> new object of that type. When osize is some other value, Lua is
> allocating memory for something else.
v
Reply | Threaded
Open this post in threaded view
|

Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?

v
On Thu, 2020-08-13 at 11:44 +0800, 孙世龙 sunshilong wrote:
> I see.
> Osize has not been used in the l_alloc() function.
> So I think it's no meaning to pass such arguments(i.e. LUA_TSTRING,
> LUA_TTABLE, LUA_TFUNCTION) to it.
> Am I missing something?

I suppose it is done for user-defined allocators so those can behave
differently for different object types for whatever reason.
Imagine implementation that somehow optimizes allocations for specific
data type, e.g. by using few memory pools with different block sizes,
or even in different type of memory: tiny and fast memory embedded into
microcontroller vs bigger but slower one connected to it externally.

Just because this is not used in default allocator implementation
doesn't mean there are no uses for it in user-defined ones.
--
v <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: tracking LUA_TTHREAD in allocators

Viacheslav Usov
In reply to this post by 孙世龙 sunshilong
On Thu, Aug 13, 2020 at 5:44 AM 孙世龙 sunshilong <[hidden email]> wrote:

> So I think it's no meaning to pass such arguments(i.e. LUA_TSTRING,
> LUA_TTABLE, LUA_TFUNCTION) to it.

This lets the allocator and therefore the host track some Lua objects.
This is of particular importance for the Lua thread objects, which the
host may have to interrupt asynchronously. This seems to be the only
way to implement such interruption generically, short of modifying
Lua's source code.

Yes, this adds overhead and complexity, and a better method built into
Lua out of the box is very much desired.

Cheers,
V.