Re: [linux-audio-dev] laaga implementation news bite

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Jun 10 2001 - 16:02:18 EEST


>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.

>> 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.

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?

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Jun 10 2001 - 17:17:18 EEST