Re: C API question

[liam mail <liam.list@...>]

>Sure it will! That is why the "user" is a programmer. This is not

>Office.  We are not in the business of providing ready-to-use solutions
>to all kinds of things users may want to do. We aim to allow users to do
>what they need by programming the primitives offered by Lua.

That is quite correct Roberto, the user is a programmer and one that counts from zero. I am asking that these primitives are left alone so that the user can choose how to use the library.

>"The fastest, cheapest, most reliable piece of code is that which
 >isn't there; design as much out of your code as you design in."

From what I can tell this is a mis-quote belonging to Gordon Bell yet I understand the point you are making, let me give you a quote of my own: Give me tools, not shackles.

On 11 January 2011 16:37, Mark Hamburg <mark@grubmah.com> wrote:

What's wrong with references? Basically, the issue is that they are dangerous in a number of potentially surprising ways. For example:

* They are uncollectable cycles waiting to happen. If you have a userdata that needs to refer to some other Lua object and does so via a reference -- a seemingly reasonable use of references -- that opens things up to a cycle that the garbage collector can't collect because the references root the objects in the registry. (The correct solution for these cases is to use the environment table for the referencing userdata.)

* They create false matches in multi-universe contexts. Since they are just allocated as integers within a universe, there is no good way to tell that a reference isn't being used in the right universe. It will still likely lead to an object, just the wrong object. Using a light userdata as a key means that you will end up at nil if you try to look for the matching Lua object in the wrong universe. (This could also be addressed by using a global, atomically incremented counter for generating reference id's rather than the existing reference mechanism.)

* References also create an initialization order problem with multiple universes if you have data like global tables needed for a C-based module where you try to track their identity via references. Unless all of the universes go through exactly the same initialization sequence, you will probably need different reference indices in the various universes. Again, a light userdata key is a much simpler solution. (This could also be addressed by using a global, atomically incremented counter for generating reference id's rather than the existing reference mechanism though the logic for when to increment the counter would need to be a bit different from the current reference logic.)

* If you use the patch to add a global-interpreter-lock to Lua, it won't actually work properly with the reference logic because the reference logic lives on the wrong side of the GIL. If you try to create two references at once, you will probably foul the reference system.

Mark

Mark thank you for outlining your concerns, yet I wonder if your main problem is "there is no good way to tell that a reference isn't being used in the right universe"? We are in C/C++ land and know this instance so well.

 

What is the defined behaviour of :

Calling the wrong delete operator on a pointer?

Using a pointer transfered over the net?

Indexing out of bounds?

Using lua_xmove to move data between different universes? (maybe this should also be removed)

Basically using a incorrect handle for the scope?

I also wonder if your concerns could be appeased if some adjustments were made locally to the core? For example using some of the bits of the handle to identify which "universe"/scope the handle belongs to maybe then, when in a debug build asserting or using some other error mechanism to highlight incorrect usage.

If you feel these problems should be brought to the wider audience and documented then maybe they should rather than, as it seems to me, implying to a programer that they can not be trusted and should have their toys removed from them like a child. If you use tools incorrectly then bad things can happen.

Liam