Matt Hurd schrieb:
I'd really like to know that the existing library is being actively and conscientiously maintained before we move on to bigger and better things.
Perhaps not too much to ask for...
I tend to agree with David's sentiment. I'd be happy to start a simplification and restructure of the basic primitives. The code should be restructured into platform specific implementations, like boost has elsewhere (such as the atomic inc for shared_prt), as the current code I find a little tricky to read.
With such a restructure the various platforms could have different maintainers to eliminate a bit of the difficulty of trying to support such a cross platform library.
This is the second time I see this happen :-( Bill Kempf, the original author of the library silently disappeared. The reason always was unclear to me. It looks to me as if he was disappointed that the C++ comitee did not accept anything of the threading work so far. Please correct me if this are wrong impressions. At least I learned this from digging through the muddy waters of the mailing list archive. Next Michael Glassford appeared, trying hard to improve on the library. I don't know what happened. I don't know whether he underestimated the task or he is beeing teared apart by something different. At a minimum I would like to hear what he has to say about the new plans. (I also BCC this to him directly.) In the end this all led to a major starvation on the threading issue. Also there are some areas that cannot be addressed with library code alone (I think): As Andrej Alexandrescu et. al. were poining out some semantic changes to the compiler are in order to provide a true multihreaded architecture. (Atomicity, memory model,...) On the other side there is a need for multithreading that can do with current compilers. (And the current library is doing quite well.)
I could pull together a basic posix-based implementation which could be used on win32 with the posix32 lib as well, though a native win32 should happen as most people would find the posix32 layer unacceptable.
I would rather like to see the current interface kept as much as possible. Did anyone yet try to find out how deeply the boost::thread is currently wired into the boost lib? I think it would be a good staring point to find this out before any interface changes are beeing introduced, or else we will end with the need to support two possibly incompatible threading libraries. And keeping the interfaces would not rise copyrigth issues would they?
Perhaps the current implementation can be refactored to do this, but starting from a clean slate so that the work can be licensed under the boost license might be best.
Refactoring looks attractive to me, but keep the interfaces.
Level 0 - basic atomic ops, fencing, thread, mutex (normal, recursive, rw), condition - to be replaced and updated with the work happening elsewhere by Lea, Boehm etal. This should also replace the atomic ops used by shared_ptr over time. Should be in a style that suits generic programming via a consistent interface which is currently lacking.
Level 1 - futures, threadables, message queues, etc, primitives along the direction of Henney's work.
Level 2 - Framework abstractions to architect single process, multi-process, multi-computer workflows. Needs boost::net / comms to reach its potential.
I am missing TLS from this list.
Any thoughts?
I like the idea of splitting the lib to maintainer/platform a lot. But we would need to agree on a coordinated process for defining the interfaces. Any suggestions? At the same time I again announce my willingness to volunteer for the win32 part. I already gained some insight when working on the TLS implementation for windows. I also attempted a clean rewrite of TLS (using the same interfaces) for the windows platform, that resulted in a aprox 4times speed improvement. Unfortunately I never had a chance to discuss this on the list. Then I suggested a so called thread alerter which can also solve most of the practical thread cancellation issues. (It is not true cancellation though.) Considering the constant requests for addition of thread cancellation, surprisingly there was almost no feedback on this at all Regards Roland