From: scott (scottw_at_[hidden])
Date: 2004-02-12 17:28:25
i have been listening-in to the recent thread thread (intentional); its
threading is a special interest for myself at the moment. i have been
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
has been the "distance" between the threading model that seems to fulfil
the requirements of my distributed messaging and the model in
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
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk