From: Scott Woods (scottw_at_[hidden])
Date: 2003-10-29 22:14:35
> > > I see the serialization w.i.p. library will be useful here. Any tips
> > > some useful boost libs / techniques to do this?
> > Cant offer any tips but can support your interest. A question though;
> > * have you looked at the state-machine work done by Andreas Huber
> Yep. Doing a new workflow thing. Did one a while back using hierarchical
> graphs using a customized GGCL (now BGL). Did a topological sort and then
> event like dynamic execution in a thread pool.
> Thinking of making the same extensions to BGL. The state machine might be
> bit too compile time oriented, but perhaps that can fit in with BGL in a
> that I need to find.
> Hmmm, a compile time hierarchical graph library that can result in parts
> being a state machine or other representation and rest being "dynamic"
> do it, but is probably too big to contemplate.
> Am considering doing a code generator from the graph representation...
> haven't thought about doing that at compile time... sounds hard.
> > I ask because you mention "strictly asynch". Or are you hoping to
> > integrate "boost transparent marshalling" with your own async event
> > system?
> Basically I wish to find an abstraction for compile time that results in a
> function/functor call, a call to queue fed threaded worker pool, a call to
> another process, or, a call to an external machine.
> I think of it as another type of sequence point where you can break out
> a different mode of execution... Changing the policy lets you simply
> the system architecture.
Very cool. Or at least what I could follow ;-)
Generally understand and "mesh" with your goals around transparent
It might be premature to jump to this point but it is a
fundamental clash of "where you might be headed" and some things
that "seem to be basic truths". Here goes.
The goal of "abstraction for compile time that results in a
function/functor call,..." is a damn good one. In everything I've
tried in my library I have been scuttled by this "truth"; something
recovered (marshalled) off a transport needs to be uniquely
identifiable, I haven't been able to do better than variations
of integer codes and that is *runtime*, i.e. the desirable
benefits of compile-time dispatch do not seem to be achievable
at the receive end of a marshalling process.
So currently my library does not target that :-( If you have
figured out some workaround then I will be throwing all my
toys out of the cot...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk