1Process Management
2==================
3
4BApplication execution
5-----------------------
6
7Applications will come in two types: those which communicate with the
8app_server and take advantage of its services, and those which do not.
9To access the app_server, an application must be derived from
10BApplication.
11
12When a BApplication (referred to hereafter as a BApp) is executed, the
13app constructor creates its BLooper message port with the name
14AppLooperPort. This port's id, by means of BLooper, registers its
15port_id with the app_server so that the two can communicate with each
16other most easily.
17
18When the app_server receives notification that an app has been created,
19the server creates an AppMonitor (with accompanying thread) in its own
20team to handle messages sent to it and sends a reply with the port_id of
21the AppMonitor, to which all future messages are sent. These AppMonitor
22objects are stored in a global BList created for the storage of such
23things.
24
25This setup normally requires that there is a single app_server instance running, and all
26BApplications establish contact with it. There are however several exceptions to this:
27
28- Multi-user and multi-sessions setups are possible, for example with the use of remote_app_server.
29  In this case, each user session (corresponding to UNIX 'login' sessions) can have its own
30  app_server.
31- The test_app_server is a test tool that allows to run most of app_server code in its own BWindow,
32  displayed inside the main app_server (mainly for debugging app_server code). In this case, the
33  applications are compiled with specific code to connect specifically with the test_app_server.
34
35non-BApplication execution
36--------------------------
37
38Other applications do not communicate with the app_server. These
39applications have no access to app services and do not generally pass
40BMessages. This includes, but is not limited to, UNIX apps. The
41app_server ignores such applications except when asked to kill them.
42
43While, technically, these are not limited to being non-GUI applications,
44in practice these applications are command-line-only, for the
45application would be required to (1) render the app_server unable to
46access video hardware and (2) reinvent existing graphics code to load
47and use accelerants and draw onto the video buffer. This is extremely
48bad style and programming practice, not to mention more work than it is
49worth.
50
51Killing/Exiting Applications
52----------------------------
53
54While the input server handles the Team Monitor window, the app_server
55actually takes care of shutting down teams, peacefully or not. Exiting
56an app is done simply by sending a B_QUIT_REQUESTED message to
57particular app. Killing an app is done via kill_team, but all the messy
58details are handled by the kernel itself through this call. When the
59user requests a team die via the Team Monitor, the Input Server sends a
60message to the app_server to kill the team, attaching the team_id. The
61app_server responds by happily nuking the respective team and notifies
62the registrar of its forcible removal from the roster.
63
64System Shutdown
65---------------
66
67Although the server maintains an internal list of running GUI
68applications, when a request to shut down the system is received by the
69app_server, it will pass the request on to the registrar, which will, in
70turn, increment its way through the app roster and request each app
71quit. When each quit request is sent, a timer is started and after
72timeout, the registrar will ask the server to kill the particular team
73and continue iterating through the application list.
74
75
76