Re: oaf patch to keep servers in process group

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> Is there any way you can see if it at least compiles on, say, FreeBSD?
> I'm always wary of making these kinds of changes and then being flamed
> by BSD fans. If there's no convenient way for you to do that, just go
> ahead with it.

If anyone on the list w/ freebsd wants to volunteer to try, that'd be
great. I don't have it myself.

Why don't you just try on your MacOS X box though? That's an ancient
crufy BSD in there isn't it? ;-) /me runs
 
> OAF lets you register your server as per-display rather than
> per-system at registration time. This does not require additional oafd
> instances, although the way it works is a bit of a hack. 

How does it work? I haven't seen any code in oaf that looked
display-related. Elliot says he wanted to add a "registration
location" on the display instead of in /tmp at one point.

> There's no way to make servers per-session because I can't think of
> a case where it matters. You can't run two different sessions on the
> same display at the same time, as far as I know.  And even if you
> could, it seems to me it would be fine to share out-of-proc servers
> between processes in the two sessions.

You can have multiple sessions on one display; the usual case where
this happens is that I remotely display an app from session A on the
display where most apps are in session B.

IIRC it's also completely allowed by the SM spec to have 10 session
managers managing different sets of your apps, though why you would do
that I have no idea.

The other issue here is that a display can have several sequential
user logins without reset, gdm used to do this, it may always reset
the display now though. So logically you want your server lifecycle
tied to a user session not the display lifetime.

Anyhow, GNOME is so fucked with 2 sessions _or_ 2 displays at once
right now, let alone mixing them, that these corner cases aren't
interesting, but probably if there's an API involving them we should
get it right for the sake of someone who might fix it in the future.

Havoc