Subject: Re: [linux-audio-dev] laaga implementation news bite
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Mon Jun 11 2001 - 12:07:34 EEST
On Sat, 9 Jun 2001, Paul Davis wrote:
> i had a couple of hours today to work on the multiprocess
> audioengine. its now doing its basic tasks of starting a server on a
> socket, accepting new connections from clients, waking periodically
> from poll(2), telling its clients to do some work, etc. note that i
> short-circuited the design used by abramo, in that clients notify each
> other when they are done instead of constantly switching back to the
> engine. this is partly why i am using kill(2) instead of write(2) -
> 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.
Note that here you doubled the cost compared to a pull model (you would
call it that way? I.e. I'm speaking of a model like GLAME does with
threads) - and I dont think you need an "engine" at all if
you are asynchronous anyway (at least you shouldnt depend on one). That
is, I dont like the callback at all as it is not flexible at all. You
can wrap a callback model around any other model in a small lib, but
you can't do otherwise.
> the engine has a watchdog timer to catch any instances of a client
> dying in the middle of its process() call, so that we can recover from
> it fairly easily in almost every case.
>
> the remaining work now is in properly keeping track of which clients
> are still alive, and port registration (this is slightly tricky since
> it involves something a bit like malloc(), but using shared memory
> segments in which the segment id will be an important part of the
> returned address).
Note that you'll get bite by using kill here - you'll need to lock
against concurrent signals during malloc() (If you ever allow malloc
from the signal handler).
Note that I have done shared memory management code for multiple
processes before (I have even an implementation ready - search for
datamanager in freshmeat or go to
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/DataManager/datamanager.html
you'll find the interesting part in the buffer.[ch] files.
> its small, compact, and i think fairly easy to understand. i will hope
> to send it to the list in a couple of days.
I'd like to see how you are using kill (i.e. how do you do callback
operation between a manager and a process at all!??).
Richard, who still thinks your approach is flawed.
-- 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 - 13:47:47 EEST