hi y'all, i have been listening-in to the recent thread thread (intentional); its worth it! threading is a special interest for myself at the moment. i have been working on something different (distributed messaging) and have been forced to consider threading. again and again. it seems to be impossible to address the one (messaging) without also addressing the other (multi-threading). this would come as no real surprise to anyone, but the slightly unnerving thing has been the "distance" between the threading model that seems to fulfil the requirements of my distributed messaging and the model in boost::threads. this is not intended to question the validity of that model; quite the opposite. i have wondered if my model is invalid and considered the task of "porting" the messaging code to the boost model (if not the implementation) calling it the "boost model" seems a little unfair as i think i can say it is in the spirit of other implementations such as rogue wave's. recent work has taken me on a different path. i have been cornered into applying my messaging+threading model within a significant body of complex production code. millions of lines of code and dozens of threads. the interesting thing (for me :-) has been how effectively the new threading model has integrated with the existing model(s). this did make me feel better about the track i had taken. so, is there room for 2? very briefly, the boost model treats threads as a resource (fair enough to :-) and submits code fragments for asynchronous execution. in the alternate model, threads come about as a consequence of instantiating final (a la java) objects. the distinguishing attribute being that threads only run code that is "part of themselves" rather than code being submitted from "outside". execution of the code is initiated by sending of a message (within my vocabulary that is actually a signal). the message can contain arbitrary data. is this different enough? is there enough value there? cheers, scott