[MPlayer-dev-eng] [PATCH] vo_macosx: option to set shared buffer name to allow multiple instances

[Adrian Stutz]

On Tue, Dec 9, 2008 at 3:26 PM, Reimar Döffinger <
Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> What is the point of making it a command line option instead of e.g.
> just appending the pid so it works also for non-commandline users?
>

Just like the shared_buffer option, it's not really intended for the user to
set but for the frontend gui, which needs to implement the correct shared
memory and NSConnection.

Appending mplayer's pid would break the way how initialization currently
works between mplayer and the gui:
The gui creates an NSConnection named "mplayerosx" and waits for an mplayer
instance to connect. When mplayer opens, it creates a shared memory named
"mplayerosx" and connects to the NSConnection with the same name. The gui
then gets the video parameters through the NSConnection and opens the shared
memory named "mplayerosx".

Appending mplayer's pid would either require for the gui to halt mplayer's
process to initialize the NSConnection or to reverse the way initialization
works.

An option would be to use the parent's process id in mplayer (given that
would work reliably - I haven't tested). This way the gui could initialize
the NSCnnection with it's own pid and the mplayer instance could then
connect to it with the parent's pid.

This would however break backwards compatibility with current guis or
require an option (command line / compile-time ?) of it's own. I don't know
if breaking backwards compatibility is a problem. If it is, then I don't
think using the parent pid would be such an advantage over the current
patch.

Greetings
Adrian