Hi, all... I've been testing the following COLA patches for the past few weeks, and want to know if anybody's interested in development along these lines. Feedback would be good, because that will help determine where I put my energy.
You can find instructions on how to download and install these unofficial patches from: http://vpri.org/fonc_wiki/index.php/Sources Here are the patch names (in dependency order), and their descriptions: libjolt-fixups.patch: Get libjolt working again. mercurize.patch: Add Mercurial infrastructure. makefile.patch: Build environment enhancements. doc-fixes.patch: Documentation fixes. gcc-is-picky.patch: Fix errors caused by picky compilers (notably late 3.x GCC). friendly-make.patch: Update Makefiles to be more friendly. explicit-precedence.patch: Enforce explicit operator precedence around math-like selectors. jolt-libid-primitive.patch: Export only _libid as a Jolt primitive. message-send-descriptors.patch: Change ABI to use __send structures. send-argument_count.patch: Add #argument_count to the idc-generated send structure. thread-objects.patch: Create per-thread objects that hang off of struct __send to store thread-specific data. dynamic-closure.patch: Define (dynamic-closure ...) to allow Jolt to create dynamically-scoped BlockClosures. per-object-metadata.patch: Add a new meta object before the vtable. multithreading-madness.patch (work in progress): Implement threading in a Jolt test program by dynamically installing a read-write lock in each object, and updating the _libid multithreading primitives for pthreads. I'll probably break the multithreading-madness.patch up into smaller pieces: one for the object trace mechanism (which works, but is not yet complete), one for a pthreads-only test, and one for a windows threading test. A nice side-effect of the object trace mechanism is that it may lay the foundation for precise GC in the future. The multithreading patch uses lock-free algorithms for all the libid.c reads (such as _vtable lookups), and per-object write locks for updates. By also putting the method cache in the per-thread object, I'm hoping that the most heavily-used code (namely _libid->bind) won't be a bottleneck. The main reason I'm working on multithreading-madness is that there was a comment on Lambda the Ultimate which suggested that COLA would only be appropriate for single-threaded programming. I'm wanting to add these features sooner rather than later so that they will mature alongside the compiler (since, as we all know, Threads Cannot Be Implemented As A Library(TM)). Have fun! -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
