Re: Gnome Session Services Framework
- From: Mark McLoughlin <markmc redhat com>
- To: Ray Strode <halfline gmail com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Gnome Session Services Framework
- Date: Wed, 27 Jul 2005 17:16:47 +0100
Hi,
The session services stuff uses D-BUS activation in order to start the
desktop at login. It works something like:
- We request the service be started using StartServiceByName using
its D-BUS service name
- D-BUS launches the program and at some point the program acquires
ownership of the service name
- The session manager gets notified that its started successfully via
via the NameOwnerChanged signal
- If we get a NameOwnerChanged signal later, we know that the program
has crashed and needs to be re-started
For various reasons I'm not entirely sure it makes sense to use D-BUS
notification:
- We're not actually interested in using the D-BUS service acquired by
the app - i.e. there isn't actually much of a requirement for the
session manager to send messages to the app
- It actually winds up being quite complicated to do it this way. I'd
be worried about this extra complexity adding extra points of
failure
- Because of the complexity, we need a library for the service side
- That second data file describing the service
- The env variables problem[1] - i.e. the session manager can't
(easily) set any env variables for the service
So, just for the sake of discussion, here's a counter proposal for
something much simpler and low-tech:
- The .desktop-service file would contain the command line for the
service
- The session manager launches the services directly with fork() and
exec()
- We use SIGCHLD to watch if the app has crashed and needs to be
re-started
- We use startup-notification in order to be notified when the app
app has fully started up
- In the normal case, if we want to stop a service (e.g. at logout),
then we just kill it
- If an app really needs to be notified that its about to be killed,
it could have a %p argument on its command-line which would cause
the session manager to pass it the read side of a pipe which the
app should poll() on. When the session manager closes its side, the
app should shut down gracefully.
Thoughts?
Cheers,
Mark.
[1] - I think we'll wind up needing to fix this for D-BUS somehow anyway
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]