[Clam-devel] subnetworks interfacing - NE several opened files

[David García Garzón]

On Thursday 24 July 2008 17:24:05 Pau Arumí wrote:
> On dj, 2008-07-24 at 16:53 +0200, David García Garzón wrote:
> > El Thursday 24 July 2008 16:33:49 Karsten Krispin va escriure:
> > > Am Donnerstag, 24. Juli 2008 10:51:37 schrieb Pau Arumí:
> > > >         Network subnet;
> > > >         subnet.AddProcessing(..);
> > > >         ...
> > > >         Network net;
> > > >         net.AddNetwork( subnet );
> > > >
> > > >         Or maybe we should generalize Processing/Network -> Module?
> > > > so net.AddModule
> > >
> > > Sorry for jumping in...
>
> Nice you jumed in...
>
> > > It might be tough approache, but what about considering a Network to be
> > > a Processing?
> > >
> > > If a network tells a Subnetwork to process it's childs, simply the Do()
> > > of the Subnetwork gets called and in turn calls it's internal flow
> > > control.
> > >
> > > That way you don't have to bother about childs' scheduling through
> > > serveral levels of the hierarchy.
> >
> > That's a good point, and that would be a solution easier to reach, closer
> > to current ProcessingComposites. But i think that splitting the flow
> > control does not provide as many scalability enhancements as for the user
> > interface. Indeed i guess you may end up having higher latencies. Pau,
> > who is developing a new schedule algorithm for his thesis could confirm
> > that or not, but i see it like considering an irregular tetris piece set
> > as a rectangular box in order to fit several of them in the minimal
> > space.
> >
> > Is that the point, Pau? (a new chapter for your thesis on scability?)
>
> 
> In terms of composition structure, yes, both leafs and a composites
> (processing and network) should be treated uniformly as components.
>
> But in terms of running it have its problems.
> The tetris metaphor is a good one: we want the flow control to generate
> iterative schedulings (that is processing execution lists) divided in
> callback activations. The callback activation is defined by the input and
> output ports connected to the backend driver (Jack, Portaudio, Ladspa,...)
> Therefore, forcing subnetwork to also run in complete "callback
> activations" is too restrictive, and could lead to non optimal latencies in
> the upper callback --what the user sees or hears.
>
> Also, we'd like to have networks whose ports do not have all the same
> execution rate (imagine a subnetwork that performs 44kHz->22kHz rate
> conversion, with the same port size). While it is impossible to say what is
> an individual Do of this network (or a callback activation), seeing the
> flattened network all makes sense (or the network have rate mismatches and
> can not be executed anyway)
>
> BTW David, the new callback-based static scheduling is ready (and tested)
> but implemented in python. I'll work on a proper integration after the
> summer.

Great news!!