What is the Spawn Service?
The SpawnService within KOS is a service whose primary responsibility is to start/stop native programs. It preforms this function across the nodes of a device. All the programs started via the service are monitored by KOS and will be restarted using a back-off algorithm in the event they crash. The SpawnService is the preferred way to start long-running processes on KOS. A good example of a program typically started with the SpawnService would be an adapter, since adapters are native programs that typically need to be restarted if they crash.
Understanding a Spawn Process
Before diving into the SpawnService, it is first important to understand how KOS abstracts the processes it runs. Such processes are represented with a SpawnProcess. SpawnProcess is pretty straightforward. A common example of such a process would be an Adapter. For the sake of brevity, this article will not go too deep into all the methods available, rather focusing on the ones unique whose function is unique to KOS. These include setLogFile(), and the pair of setListener() and getListener().
The first of these allows the user to specify the name of a log file. this file will be created in the log directory, and the output of stdout and stderr redirected to said file. If such a file is specified, then the I/O stream of stdout and stderr will be disabled. This cannot be changed after the process is started.
the second of the three methods mentioned allows a user to attach a listener to a SpawnProcess. This way the listener can receive lifecycle events from the listener. As one can imagine, getListener() simply returns the specified listener.
As mentioned earlier, there are a variety of other methods within SpawnProcess that can be found in the javadocs here.
How to use the Spawn Service
There are only a handful of methods within the SpawnService, and most of them are straightforward in nature; this article will briefly cover some of them. The two methods used most often would be addProcess() and addDaemon(). These methods, as their name might imply, are responsible for adding a specified SpawnProcess to the SpawnService, either as a normal process in the case of the former, or as a daemon in the case of the latter. In the case of a daemon, if for whatever reason the process self-terminates, it will be automatically restarted by the SpawnService.
Additionally, these two methods have variations which allow the user to specify the NodeId of the node they would like the process to run on. If a node is specified and the iface to said node is already established, the process will start immediately. Alternatively, if the iface is not there, then the process will be stored and started once it appears.
It should be noted that addDaemon() is more of a convenience method, and only ensures that the Daemon flag of the SpawnProcess is set to true. If a SpawnProcess has its daemon flag set independently and then is added with addProcess() the effect will be the same.
Just as one can add a process to the SpawnService, one can remove them as well. This is done with removeProcess() method which kills the specified SpawnProcess. This method is commonly used to deal with daemons which are no longer needed. For situations where you want to kill a daemon but let the SpawnService restart it, there is also the restartDaemon() method, which does exactly that. This is commonly used to reset a daemon if it starts to preform incorrectly.
Furthermore, in regard to daemons, users have the option of fetching all the daemons running on either the local or a specified node with the getDaemons() method of the SpawnService. In the case of the latter, similar to addProcess() and NodeId can be passed to indicate the target node.
Finally, the SpawnService also allows users to set the priority of a process by calling setPriority(SpawnProcess process, int priority). The priority dictates how much CPU time the process will receive and follows the UNIX standard of 0 for default, 19 for the lowest priority, and -20 for highest priority.