Ian Piumarta Ian.Piumarta@inria.fr wrote:

...

Surely, simply using the table in sqNamedPrimitives.h in the way it is intended to be used will do this?

I've done nothing to the the way sqNamedPrims works. For internal prims, the lookup is identical to all the other platforms.

...

The lookup for internal named prims is done _only_ via the table. Since 'exit' is not in the table, it can't be wrongly called. Scratch one dumb way to shoot oneself in the foot. No worries.

But the "problem" occurs when looking in an external module, not an internal one. When dlsym() looks up a symbol it searches in the named .so and then in the global namespace. There is a flag in one of the Unix standards definitions somewhere called RTLD_LOCAL that can be `or'ed with the dlopen() "mode" argument to cause subsequent dlsym()s to look only in the .so itself, and never in the global namespace. But I don't know how portable this is.

I'm not into all details of this but consider the following:

Instead of having one central table that can be used in a portable way to find things, distribute this table so each module has its part of the table. The only thing that should be linked when loading a module is this table. Everything else, that is the real content, is fetched throw this table. I have used such a scheme for a long time and find it very good. It is possible to associate explicit types with each method/function that can make it easy to call things in a coherent way. The Python folks are using a scheme similar to this I believe.

In such a module everything is static (= local) except the table.

Another twist is to fix numbers for each primitive within the module with an "enum" and then, having a Squeak representation of the same enum, it becomes possible to use array access directly, narrowing the gap between oldtime numbered primitives with the newer named ones.

I am going to look into these kinds of things in the near future and will have more to say.

/Mats