Paul Davis wrote:
>
> >I don't understand of what you're speaking: in my design for multi
> >process model the switch back to the engine happens only once for each
> >period (as it's needed).
>
> Yes, but thats because your example didn't solve a rather fundamental
> problem of resorting the graph.
It seems you're rather confused... nobody expected that that program
solves that...
What I say is that pipe approach has not the repetitive switch back
drawback you believe to have seen there.
> >> its easy to shuffle a set of PIDs to be signalled to match the
> >> processing graph; getting each client to have an fd to talk to every
> >> other client is far from trivial.
> >
> >If you're thinking to change connection graph preserving component
> >processes the only way is either:
> >1) to use named pipes
> >2) to pass file descriptors using UNIX socket.
> >
> >The latter is the more elegant option IMO (and more safe), and you may
> >use the same communication channel you need between engine and
> >components.
>
> there are two interpretations of "passing". the linux kernel has had
> support for literal "handoff" of a file descriptor for some time. this
> is much more than telling one process to "use" an existing file
> descriptor, but actually involves transfer of the fd from the
> filetable of one process to that of another. this is the "strong"
> interpretation of "passing". the "weak" intepretation, which is closer
> to how I read your suggestion, is that one process tells another
> process to "use" an fd that the second process already has open.
>
> in the strong case, this uses technology that i'm wary of and is not
> part of POSIX IIRC.
This is what I'm referring and seen the presence of SCM_RIGHTS in
http://www.opengroup.org/onlinepubs/7908799/xns/syssocket.h.html I
suppose you don't remember correctly.
>
> in the weak case, its an architectural nightmare to establish
> connections between every client, and i don't want to go there.
>
> hence the use of signals; every client has a shared memory control
> block in which the engine just scribbles the PID of the process the
> client should signal next. this representation of the graph can be
> changed trivially and without any out-of-band notification to the
> component processes.
>
> >Note also that signals may have some non atomicity troubles.
>
> such as?
Go to sleep *after* signal has been received (same problems that's faced
with pthread_cond_wait semantic).
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
