[alsa-devel] Surrogate Parent Model / How to close ALSA device nodes?

[Daniel Yek]

Rémi Denis-Courmont wrote:
> On Thu, 22 Oct 2009 15:55:33 -0700, Daniel Yek <dyek at real.com> wrote:
>> Could it be that the answer is to use the surrogate parent model?
>> Book: Pthreads Programming:
>> That is, the multi-threaded app. creates a dummy child process during
>> its initialization process and use the child solely as a surrogate
>> parent to fork on behalf of the app. That way, the multi-threaded app.
>> doesn't have to fork and possibly leaking "states" in the child
>> (especially, if it is not followed by an exec(), I think.)
>>
>> I'm interested in hearing from the more experienced devs. regarding this
>> technique too.
>
>   
> That works if you have a stand-alone program that forks "early", though
> this really is not too nice. You need to transmit the executable program
> parameters over some IPC mechanism. Also, this incurs some obvious memory
> and CPU overhead.
>
> However, most multimedia frameworks are layered into libraries and
> plugins,
> so they don't have their own process to fork early enough, so they cannot
> do that. In my particular bug, we have the ALSA plugin leaking the
> descriptor, and the XDG screensaver plugin doing fork-and-exec.
> Synchronizing those two is not really an option.
Hi,

[Not trying to say that it is a solution or I know a lot about the
model, but just to comment on the possibility more...]

I suppose in the crude way, the program can call the multimedia
framework's init function early to fork the surrogate parent and provide
forking services. Plugins, etc., should use the framework's service,
instead of simply fork.

I further suppose that the a fork-exec DSO can be created and the
LD_PRELOAD mechanism used to "redirect" all fork() and exec() (and
what-else) to the DSO implementation, which utilizes the DBus 1-to-1 IPC
(for convenience, or any custom wire protocol) to the surrogate parent,
which then implements fork(), exec(), waitpid(), etc.

I'm not sure yet if DBus provides file-descriptor-passing services, if
not, fds can be passed (explicitly -- not great, cumbersome, but it
might be necessary) the way it is -- using another Unix domain socket
connection, if necessary.

XDG screensaver can be called in a child process too -- the surrogate
parent is adequate for this too.

There is a possibility that this model can work, but I have never
actually trying it out, just thinking about it often. If this works, it
would be a great addition to Glib.

I hope there are other more experienced people chime in to offer
(appreciated) comments.

Regards,

-- 
Daniel Yek.