Erlang/OTP pattern to ensure Composite process accepts a message only when children are done -

is there erlang/otp pattern/library following problem(before hack own):

• at highest level, imagine there 3 components(or processes?) such a->b->c -> means sends message to.
• b in terms of architecture composite process. composed of many unit processes(shown in khaki green below). sometimes, message chain goes b1->b2->b3->c , goes b1->b4->b5->b6->b3->c.

what is:

• b can accept next message when it's children processes done i.e b receives message i1 , depending on message, choose 1 flow , c gets message o1. until happens, b should not accept message i2. ensure ordering of messages o2 of i2 not reach c before o1 of i1.

this has few names. 1 "dataflow" (as in "reactive programming" -- sort of overblown ball of buzzwords if up) , "signal simulation" (as in simulation of electrical signal switches). not aware of framework in erlang, because straightforward implement directly.

the issue of message ordering can made take care of itself, depending on how want write things. erlang guarantees ordering of message between 2 processes, long messages travel in well-defined channels, system-wide promise can made work you. if need more interesting signal paths straight lines can force synch communication; though erlang message asynchronous, can introduce synchronous blocking on receive wherever want.

if want "b constellation" pass message c after signal processing has run route through b's, can make signal manager sends message b1, , blocks until receives output b3, whence passes completed message on c , checks box next thing a:

a_loop(b) ->   receive {in, data} -> b ! data end,   a_loop(b).  % note 2 receives here -- blocking end of processing based % on known ref send out , expect receive in message match. b_manager(b1, c) ->   ref = make_ref(),   receive data -> b1 ! {ref, data} end,   receive {ref, result} -> c ! result end,   b_manager(b1, c).  b_1(b2) ->   receive     {ref, data} ->         mod1 = do_processing(data),         b2 ! {ref, mod1}   end,   b_1(b2).  % here have many "b_#" processes need...  b_2(b) ->   receive     {ref, data} ->         result = do_other_processing(data),         b ! {ref, result}   end,   b_2(b).  c_loop() ->   receive result -> stuff(result) end,   c_loop(). 

obviously drastically simplified things -- in doesn't include concept of supervision -- didn't address how want link these (and little checking liveness, need spawn_link them if dies die -- want b subset anyway, can treat single unit). also, may wind needing throttle in there somewhere (like at/before a, or in b). speaking, way of passing messages through in way makes b block until segment of processing finished.

there other ways, gen_event, find them less flexible writing actual simulation of processing pipeline. far how implement -- make combination of otp supervisors , gen_fsm, these 2 components represent perfect parallel signal processing components,which system seems aimed @ mimicking.

to discover states need in gen_fsms , how want clump them prototype in very simplistic fashion in pure erlang few hours, make sure understand problem, , write proper otp supervisors , gen_fsms. makes sure don't invested in temple of gen_foo behaviors instead of getting invested in solving problem (you're going have write @ least twice before right anyway...).

hopefully gives @ least place start tackling problem. in case, natural sort of thing in erlang -- , close enough way language , problem work should pretty fun work on.