[Commotion-dev] [commotiond:obj] Garbage collection and object flags initial proposal (w/ notes on lua roadmap)

[Luis EG Ontanon]

the Lua interface is on its way...

First I'm coming out with a full wrapper for commotionlib, that should
allow to write a full blown client or daemon in Lua. Later, as I get
more acquainted with the API I will think in how to get it to work in
a "modular" way "within commotionlib".

In the next few days I'll be done with the code generator and within
the next few weeks the LuaAPI should be compiled and ready for the
next step:

To run leaking almost everything... to allow me to understand what's
needed for correct garbage collection: The issue is that Lifespan of
different objects, differs from their presence in Lua, some exist only
while "in Lua" (and get destroyed by it) some others are to be
delegated to someone else, while some are just to be left alone).

It is evident to me that the solution to the problem goes through how
to use the flags field of co_obj_t .

The key to successful memory management is having a clear idea of who
is to take care, when and how,  of the destruction of objects ( "the
trinity" of garbage collection).

So evidently what we need to convey in the flags field is enough
information to be able to easily come out with this "trinity".

I was thinking in using few of the LSBs to convey "who" is delegated,
an leave the MSBs to "the delegate" as each one has its own demands.

some of the values I'm thinking for the "who subfield" are:
 - "somewhere in the stack"... a return will destroy it... (useful to
know as I may want to make my own copy if it has to predictably
persist)
 - "no one" static object.. will persist forever..
 - one of some "actors": e.g. the Lua machine, This or that module.

In this scenario and we need to define some methods to delegate between actors.

Cheers,
\Lego
-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan