History log of /haiku/src/servers/launch/Job.h
Revision Date Author Comments
# a77aa747 25-Apr-2018 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added basic logging facility

* The daemon now stores many events in am internal log.
* You can use "launch_roster log" to retrieve it.


# 6d7b8a30 04-Dec-2017 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Renamed TeamRegistrator to TeamListener


# 59e6d9d2 27-Nov-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Maintain pending jobs for requirements.

* If a requirement cannot be launched, a job is now added to the
requirement as pending job.
* If the requirement enters the launch queue at a later time, the
pending job will be put there, too.


# 9e73b627 11-Nov-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Fixed preregister consequences.

* Since the last change, the user launch_daemon would talk to the
registrar again.
* However, this also caused BRoster::Launch() to preregister the app,
which messed up our preallocated port.
* BRoster::Private::Launch() now allows to get the port that the
registrar created in such a case, and the launch_daemon will now just
use that one as default port.
* This lets us talk to the Deskbar again, and should fix #12455, as
well as #12454 (again).


# 70708ef9 10-Nov-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Retrieve default port from monitoring BRoster.

* Instead, we now maintain a default port for a job. For "legacy"
services, BRoster's B_SOME_APP_LAUNCHED will update it, too.
* This allows to quit Tracker using "launch_roster stop".
* Also, this fixes bug #12249, as we don't use the signature variant of
creating BMessenger anymore in Job::GetMessenger(). This would call
into the launch_daemon again, and deadlock.


# 5860caae 07-Nov-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added basic ability to stop/start jobs via API.

* Stopping a job is very simplistic right now, and will have to be
extended considerably, probably with its own job.


# e2f83cbd 06-Nov-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Monitor teams, and restart services.

* Services that end are now automatically restarted.
* However, this is very basic at the moment, there is no throttling,
and no support for shutting down the system.


# 4ae4b3ff 18-Oct-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Fixed the remaining "operation not allowed" bug.

* This was the harmless part: a job was been requeued that already was
being launched.
* I was already aware of this one, and only accidentally stumbled over
the non-harmless case in the JobQueue code when I tried to fix that
little issue... (ie. never ignore warnings, even if you think you
know what's going on).


# 7cd19b7e 17-Oct-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Implemented sticky events, and registration.

* Sticky events are events that keep their signal raised, ie. even if
a job is initialized afterwards, it will still be triggered.
* Consolidated naming for external events.
* Events are now registered once they are actually being used. This
allows them to allocate the resources they need to do their thing.


# 5cf6c0fd 28-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

launch_daemon: Create/inject ports on launch instead of upfront.

The application is now launched suspended and the ports are created
and transferred to the launched team before its main thread is
resumed.

The ports are therefore owned by the launched team instead of the
launch_daemon. This is important when sending messages by area, as
the port owner is used to determine where the data area needs to be
transferred to. This commit therefore fixes #12285.

Note that it is still possible to get at the ports with find_port()
while they are still owned by the launch_daemon. This should not be a
problem however, as these ports are not supposed to be found this way
but only through BLaunchRoster::GetData(), which is synchronized with
the above process.

Creating the ports in the launch_daemon still has the benefit of
returning valid communication ports earlier, i.e. without having to
wait for the launched application to actually become ready.


# 14156a33 26-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

launch_daemon: Delegate launch data replies to Job.

Previously the LaunchDaemon would send out its own team id when a given
job was not yet launched, leading to invalid BMessengers once the port
owner changed to the actually launched team.

The launch of the target team and the launch data replies were also not
synchronized, which could lead to the launched team getting a reply
pointing to the launch_daemon when requesting data for itself. This is
the case for the BRoster init of the registrar. The fix in hrev49561
therefore didn't always work, because the registrar would sometimes get
the launch_daemon team id instead of the id of itself. It would later
try talking to the launch_daemon, which obviously never replied, leading
to #12237.

The LaunchDaemon now delegates the launch data reply to the Job instead.
The Job either replies directly, in case it has already been launched,
or queues the reply for when the launch completes. This causes launch
data requesters to block until the launch attempt is completed, but
won't block the LaunchDaemon message loop.

This commit introduces the seperate fLaunchStatus to properly handle the
ambiguity of fTeam being < 0, which is the case for both, when no launch
was attempted and when the launch failed. This new field now determines
what IsLaunched() returns and how launch data replies are handled.

The new launch status is additionally protected by the launch status
lock, which will later probably be made broader in scope to protect
against race conditions once service monitoring is implemented.


# 2ca4f3f8 17-Jul-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Jobs were started before their target.

* A job must not be launched when its target hasn't been launched
yet. This fixes Tracker launching when the mount_server scanned
the initial disk, even though the FirstBootPrompt was showing.
* Jobs are no longer initialized when their target has not been launched
yet. This also means that you cannot talk to a service beforehand in
this case.
* Slight refactoring and clarifying, even added some documentation :-)
* _TriggerJob() is now called _LaunchJob(), and does all the checks for
jobs that _LaunchJobs() does now for targets.


# ea19a80e 06-Jul-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added support for setting env.

* We cannot "source" files through a shell yet, though.


# e0fc09b4 25-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Conditions now know if they are constant.

* This allows to remove a job in the init phase already, if its
condition is not only constant, but also failing.
* Also removed the special Job::LaunchInSafeMode() method; this is now
done using the conditions (the config option no_safemode remains,
though).


# 1e9c9871 22-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added basic support for conditions.

* Admittedly not very well thought out, but it should be good
enough for now; it doesn't really make sense to initialize jobs
that is never run due to failed conditions.
* Job, and Target now have a common base class BaseJob that deals
with the conditions.


# 8b8780bf 15-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Moved Job+Target into separate files.


# 5cf6c0fd3b9fe36a587bd712eade8045ea4cc723 28-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

launch_daemon: Create/inject ports on launch instead of upfront.

The application is now launched suspended and the ports are created
and transferred to the launched team before its main thread is
resumed.

The ports are therefore owned by the launched team instead of the
launch_daemon. This is important when sending messages by area, as
the port owner is used to determine where the data area needs to be
transferred to. This commit therefore fixes #12285.

Note that it is still possible to get at the ports with find_port()
while they are still owned by the launch_daemon. This should not be a
problem however, as these ports are not supposed to be found this way
but only through BLaunchRoster::GetData(), which is synchronized with
the above process.

Creating the ports in the launch_daemon still has the benefit of
returning valid communication ports earlier, i.e. without having to
wait for the launched application to actually become ready.


# 14156a33ac0233f4233546080d6b975618b331fa 26-Aug-2015 Michael Lotz <mmlr@mlotz.ch>

launch_daemon: Delegate launch data replies to Job.

Previously the LaunchDaemon would send out its own team id when a given
job was not yet launched, leading to invalid BMessengers once the port
owner changed to the actually launched team.

The launch of the target team and the launch data replies were also not
synchronized, which could lead to the launched team getting a reply
pointing to the launch_daemon when requesting data for itself. This is
the case for the BRoster init of the registrar. The fix in hrev49561
therefore didn't always work, because the registrar would sometimes get
the launch_daemon team id instead of the id of itself. It would later
try talking to the launch_daemon, which obviously never replied, leading
to #12237.

The LaunchDaemon now delegates the launch data reply to the Job instead.
The Job either replies directly, in case it has already been launched,
or queues the reply for when the launch completes. This causes launch
data requesters to block until the launch attempt is completed, but
won't block the LaunchDaemon message loop.

This commit introduces the seperate fLaunchStatus to properly handle the
ambiguity of fTeam being < 0, which is the case for both, when no launch
was attempted and when the launch failed. This new field now determines
what IsLaunched() returns and how launch data replies are handled.

The new launch status is additionally protected by the launch status
lock, which will later probably be made broader in scope to protect
against race conditions once service monitoring is implemented.


# 2ca4f3f81d28b528d479f95e29cf6f936e2c7dc7 17-Jul-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Jobs were started before their target.

* A job must not be launched when its target hasn't been launched
yet. This fixes Tracker launching when the mount_server scanned
the initial disk, even though the FirstBootPrompt was showing.
* Jobs are no longer initialized when their target has not been launched
yet. This also means that you cannot talk to a service beforehand in
this case.
* Slight refactoring and clarifying, even added some documentation :-)
* _TriggerJob() is now called _LaunchJob(), and does all the checks for
jobs that _LaunchJobs() does now for targets.


# ea19a80ed6ba3f34abb2e4d138ddc666580b8d82 06-Jul-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added support for setting env.

* We cannot "source" files through a shell yet, though.


# e0fc09b439b66df0e35c159d0b5b055cde7d2792 25-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Conditions now know if they are constant.

* This allows to remove a job in the init phase already, if its
condition is not only constant, but also failing.
* Also removed the special Job::LaunchInSafeMode() method; this is now
done using the conditions (the config option no_safemode remains,
though).


# 1e9c98710286129c9161f29787742b1ea2bff449 22-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Added basic support for conditions.

* Admittedly not very well thought out, but it should be good
enough for now; it doesn't really make sense to initialize jobs
that is never run due to failed conditions.
* Job, and Target now have a common base class BaseJob that deals
with the conditions.


# 8b8780bfe399a2a8058f4620e5f33f74db097ca2 15-Jun-2015 Axel Dörfler <axeld@pinc-software.de>

launch_daemon: Moved Job+Target into separate files.