Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Mon Jun 11 2001 - 19:31:14 EEST
On Mon, 11 Jun 2001, Paul Davis wrote:
> >Ok, thats code I understand. How is this different from the GLAME
> >approach which does (same scope as your example):
> >
> > client (within a library, wrapping up a callback like operation)
> > read(inputportfd, &control, 4);
> > switch (control->event) {
> > case ProcessEvent:
> > registered_process_func (control->buffer ...);
> > break;
> > ...
> > }
> > write(outputportfd, &control, 4);
>
> its not different at all as long as the "connections" represented
> by inputportfd and outputportfd remain static.
>
> but what happens when this particular client is now supposed to run
> later in the graph? how does inputportfd and outputportfd get reset to
> point to the correct "next" client ?
You have the same "race" with your approach - just doing the forward
from the client does not work if f.i. the supposed to be next client
is either re-routed or deleted during operation.
> suppose the current execution order (based on the flow graph) looks like:
>
> worker1
> worker2
> worker3
> worker4
>
> now the user reconfigures the graph by adding/removing some connections,
> and the order is now:
>
> worker3
> worker1
> worker2
> worker4
This "reconfiguring" needs to be in multiple atomic steps:
1) remove connection from worker3 to worker2
2) remove connection from worker3 to worker4
3) add connection ...
4) add connection ...
where remove connection would just close the fd's (so pending
reads/writes will just return with an error which the above
code may need to handle explicitly) and add connection would
instantiate a new pipe (and you need to signal the connected
components to update their knowledge about their connections).
Note that you cannot avoid "loosing" frames during such operation
(obviously - a worker reorder is not an atomic operation - making
it atomic would involve "stalling" execution and such probably
lead to other problems as well).
> how you do you propose to reconfigure the execution of a set of
> external processes to reflect the new order? its easy to do this with
> internal clients (plugins), but not with external ones, since they
> each need (1) to know who is next and (2) to have some way of
> notifying that client that its "their turn" ...
>
> if you use read/write then as far as i can see this would mean that
> every client has to have an fd connected to every other client, and/or
> would have to reconfigure its fd's every time the graph changes. true?
You would have to, but so do you (update your graph).
Richard.
> --p
>
-- Richard Guenther <richard.guenther_AT_uni-tuebingen.de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
This archive was generated by hypermail 2b28 : Mon Jun 11 2001 - 20:55:11 EEST