Notes
(Idea) Catch uncaught signals by catching "RuntimeError
.UNCAUGHT".
ABORTED might be nice too. Send mail to implementer and user. Check with controller to insure that only 3 errors are mailed - to avoid overload of Gravevine and user. (Register by calling RuntimeError.RegisterUncaughtSignalHandler; it currently goes to AMEventsImpl.MyCatcher.)
Register by calling RuntimeError.RegisterUncaughtSignalHandler. The normal call goes to AMEventsImpl.MyCatcher. Remember where it used to go, and send unknown signals off that way. Look on the process property list to see if this is a remote process.
Duplicate the AMEventsImpl.MyCatcher code, except for the call to LocalEvent. Call AmEventsImpl.SignalEvent (must SHARES) to get an AMEvents.Event. Do the LocalEvent body (copy it), but have a different InvokeEvent. Normally, this calls InterpreterToolImpl.EventHandler, which (for non-nested calls to the interpreter) just calls CreateTool. This pokes about for a bit, then if there is not a dormant Event window laying around, creates a new InterpreterObject and calls NewViewer with it. Next it calls MainLoop to do the processing. Looks like I can use it too - it reads a stream and writes a stream as its basic functions. So, build the RPC interface to map the buttons and another one to do the startup (server -> client).
(Old) To raise FS errors, raise it as the real FS.Error, catching RuntimeError.UNCAUGHT. If caught, RESUME and then raise my FS.Error.
(Old) Make new services by accepting a .bcd and .load file pair (the .load may be ommitted), together with an optional version number. Bind the .bcd, and perform some post processing that is driven off of two lists: a illegal interface and a replace map. Illegal interfaces (e.g. File) cannot be imported. In addition, entries in the replace map will cause the imported interface to be bound with the replaced module (e.g., FS -> my FS implementation). If all is well, the software enters the output file, load file and version into the available command database.
Provide single bcd so that compiles can be local or remote.
(Old) FS must be re-layered so that some data types may be imported instead of using SHARES.
It is possible to check file privileges by conditioning the FTP connection to the IFS as the user, and starting an FTP retrieve. You can abort this at least when the first bytes arrive. First, read the properties and check that you have world or owner access. If so, no retrieve is necessary unless you don't have the file in the cache. Flush out the file if this is a personal machine and the file was personal.
Interesting properties of machines: (total and available for server): main memory, # CPUs, CPU type, disk partition size, free GFIs, free MDS, unassigned VM, file cached with oldest LRU date, CPU load, memory load, processes
Interesting properties of commands: memory, CPU cycles, GFI, file cache, processes.
Only do a few (three?) restarts of commands when the server crashes during command execution.
Servers can do auto-rollback.
Mark all processes that are running on behalf of the server so that they can all be killed if needed. Count page faults causing disk I/O on a per process basis, and tabulate for the compute server. Look at FORK to see if we can count server processes and restrict time if needed.
Cache interfaces to the controller, and other needed interfaces.
FORK sets the child's property list to NIL! I need to provide facilities for registering FORKed children as members of a computation (task force).
New files in .df files.
Startup command lookup and all that. First, find all services by looking in /Indigo/Summoner/Top/PackageList. For all .df files in this list, not matching local .df files, do a bringover. Kill bringover if it tries to bringover a file from Environment ~= that which is in /// or ///Commands (Indigo and this list are variables from the profile or somewhere). -- old If new software is put into the system, the controller is informed, and it tells all of the servers that a new .df file is around.
.df files now have .remoteCommands and .summonerLoad entries. .remoteCommands files specify version number, maintainer list, and command list (etc.). .summonerload is like a .load file except that it is only the server part of the package and is only a list of packages to run included in the df file: the .load file only starts up the frontend (viewer) part. Local interface needed to startup locally the remote part.
To try to run a command, look it up. If found, do it. If not found because of version superceeded, fail. If nothing new, fail. If new, bring it over. Look in summonercontrol to see if the version is now right. If so, start the load sequence. If not found, but found in a data structure of the command list and summonercontrol files, start the load sequence.
A load sequence is performed by looking at the summonerload file. Try to process it like the loader would to catch version mismatch errors. (see CommandToolImpl.RunCommand, CedarLoaderImpl.Instantiate, LoadStateImpl.ConfigInfo, AMModel, WorldVM, BcdDefs, Loader, LoadState). Check to see that .bcd's that are already loaded. If not loaded but a package by that name is around, send grapevine mail. If it looks OK, load it. Catch errors, and report them back. If all this works, pick off the newly registered command and do it.
To submit a command, SModel files and then use a local commander command. The command then does the following on the local machine:
1) Insures .df file has a global attachment
2) reads and parse the df file
3) open summonercontrol and summonerload files. Check that summonercontrol parses OK and is reasonable. Check summonerload fully specified and local subdirectory files match or are newer than /// or ///Commands/.
4) (should be done) Take package bcd and generate IMPORTs. Check against list of good imports. Complain if needed. (this should be done on the controller, and be protected, but I trust people)
If all this is OK, then do a RPC to the controller and ask him to enter new .df into the master (pseudo) df file.
Track down the random closes of files: it might be finalization.
Catch FS.Error for my errors on the server and handle.
What to do when client crashes.