Hi Ian, In working on a patch to support multithreading throughout libid, Pepsi and Jolt, I had to make a distinction between the vtables (which are shared by all objects in a given clone family) and other metadata that may be per-object (such as locks, STM versioning data, debug information, etc).
I took some hints from your plan of adding another word before functions to make them both proper objects and have further attributes. Generalizing that, I've introduced struct __meta, which contains all the metadata that libid needs for basic operation (such as the _vtable pointer). My proposed oop layout looks like: | ...more metadata | +------------------+ | struct __meta | | | | | +------------------+ | METAMETA-PTR |----> an oop describing the metadata +==================+ | ...members | <--- oop points here Similar to _vtable_vtable, the terminal _metameta oop looks like: | ...more metadata | +--------------------+ | struct __meta | | | | | +--------------------+ | METAMETA-PTR |----\ +====================+ | Points to self | METADATA-SIZE | <--/ +--------------------+ | ...more members | Just like the struct __send design, this allows for users to extend an object's metadata with whatever they want. [Now if only that magical ASCII-art parser could convert that diagram into a fully-working implementation! ;)] METADATA-SIZE is the first member of every derivative of _metameta in order to compute the beginning of objects allocated using that metameta object without invoking the message send runtime. I had a good reason for that before, but I can't remember what it was. :P I'm going ahead and experimenting with this design; it will merge with my struct __send patch, since it touches many of the same pieces. Unless there are changes to the design, I hope that we can finally land these on the mainline. My multithreading changes are somewhat mixed in with all this. The architecture I have is independent of threading model: the user configures _libid with the model of their choice. However, in doing the changes, I greatly cleaned up my former struct __send patch, and stuffed a lot of libid's state into a per-thread data structure that hangs off of struct __send (as you and I were alluding to earlier). Again, the _thread object is user-extensible, if people want their own fast-access thread-specific data. After all of this (which should also implement send>>argument_count outside of libid, as an addition made by Pepsi and Jolt), I still want to make the changes to function/ so that redundant methods that have noisy keywords with arbitrary limits (such as value, value:, value:value:, value:value:value:, etc) are replaced by a single method with anonymous variadic arguments (value ...). Anyway, please let me know what you think, and happy holidays to everybody out there (best regards also to those of you who don't celebrate)! -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
