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