Process Management==================BApplication execution-----------------------Applications will come in two types: those which communicate with theapp_server and take advantage of its services, and those which do not.To access the app_server, an application must be derived fromBApplication.When a BApplication (referred to hereafter as a BApp) is executed, theapp constructor creates its BLooper message port with the nameAppLooperPort. This port's id, by means of BLooper, registers itsport_id with the app_server so that the two can communicate with eachother most easily.When the app_server receives notification that an app has been created,the server creates an AppMonitor (with accompanying thread) in its ownteam to handle messages sent to it and sends a reply with the port_id ofthe AppMonitor, to which all future messages are sent. These AppMonitorobjects are stored in a global BList created for the storage of suchthings.This setup normally requires that there is a single app_server instance running, and allBApplications establish contact with it. There are however several exceptions to this:- Multi-user and multi-sessions setups are possible, for example with the use of remote_app_server.In this case, each user session (corresponding to UNIX 'login' sessions) can have its ownapp_server.- The test_app_server is a test tool that allows to run most of app_server code in its own BWindow,displayed inside the main app_server (mainly for debugging app_server code). In this case, theapplications are compiled with specific code to connect specifically with the test_app_server.non-BApplication execution--------------------------Other applications do not communicate with the app_server. Theseapplications have no access to app services and do not generally passBMessages. This includes, but is not limited to, UNIX apps. Theapp_server ignores such applications except when asked to kill them.While, technically, these are not limited to being non-GUI applications,in practice these applications are command-line-only, for theapplication would be required to (1) render the app_server unable toaccess video hardware and (2) reinvent existing graphics code to loadand use accelerants and draw onto the video buffer. This is extremelybad style and programming practice, not to mention more work than it isworth.Killing/Exiting Applications----------------------------While the input server handles the Team Monitor window, the app_serveractually takes care of shutting down teams, peacefully or not. Exitingan app is done simply by sending a B_QUIT_REQUESTED message toparticular app. Killing an app is done via kill_team, but all the messydetails are handled by the kernel itself through this call. When theuser requests a team die via the Team Monitor, the Input Server sends amessage to the app_server to kill the team, attaching the team_id. Theapp_server responds by happily nuking the respective team and notifiesthe registrar of its forcible removal from the roster.System Shutdown---------------Although the server maintains an internal list of running GUIapplications, when a request to shut down the system is received by theapp_server, it will pass the request on to the registrar, which will, inturn, increment its way through the app roster and request each appquit. When each quit request is sent, a timer is started and aftertimeout, the registrar will ask the server to kill the particular teamand continue iterating through the application list.