From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-03-04 12:21:14
> From: Braddock <braddock_at_[hidden]>
> Subject: Re: [boost] interest in a "signal flow" library?
> However, adopting a functional style is one thing. But creating a new
> syntax which constrains you to that style, appears less expressive than
> the C++ language itself, and will undoubtedly be more difficult
> to maintain, is an act that requires considerable justification.
> I would have a legitimate need for your syntax if, for example, the
> different functions executed in parallel threads, or were queued to
> specific worker threads, if I could somehow otherwise control and
> schedule the execution of the invoked functions, or traverse the call
> graph. This could bring it closer to a "pipes and filters", LabView, or
> Petri Net design, but all are very different than straight signal wiring
> of serial processes.
Adding functionality that relates to the network as a whole (like
traversing the call graph) would indeed be a significant leap in the
usability of the library. It might take a while for me to find a good
way of doing that, but I'll definitelly try something.
The threading idea is great - I think I'll be shifting my focus to
using the thread_safe_signals and trying to tackle some of those