The Parts Server

The generate server was also written in Perl. It uses various forms of interprocess communication to accomplish its task. First, it sets up a message queue, and then creates a copy of itself, called a child, to be the master server. The original process watches the queue, and whenever a message appears in it, the process reads it, and then writes it to a log file. The server and its children send messages to this queue for various events. This allows monitoring usage of the server, and detecting problems with it.

This approach is used to prevent two processes trying to write to the log at the same time and overwriting each other. It also listens for a signal that causes it to restart the log at the beginning. This signal is sent by a maintenance program that runs every night. This program keeps one week's worth of logs, and deletes older ones. It also sorts the log entries and generates a summary of what happened during the day.

The child process then sets up a socket on the host machine, so the search programs can contact it, and waits. When it is contacted, it creates another child to handle the request, so it can keep listening for more requests. It keeps listening for requests until it gets a signal which causes it to clean up after itself and exit.

The child reads in a generate request from the other program. The request is of the form master_part member_name master_directory. The first is the name of the master part, the second is the Member_name of the needed part. These are used to create the command passed to CADDS to generate the part: generate family master_part member member_name. The third part of the request is the name of the directory containing the master part. This is used to build the name of the directory for the member part. If any of these components is missing, it reports an error and exits.

Before attempting to generate the part, the server checks to be sure that the part directory doesn't exist. If it does, CADDS may end up hanging because it needs user interaction, and the request will never complete. In order to limit the amount of resources used, the program sets a semaphore, or flag, that prevents more than one CADDS process from running at once. Therefore, if CADDS hangs, the server can not process any more requests. To help prevent this situation from happening, the child aborts the CADDS process after a predetermined amount of time.

Once the child is sure that the part directory doesn't exist, it registers a request to set the semaphore. The operating system only lets one child at a time set the semaphore. Once the request is granted, the child starts CADDS, giving it a set of commands. The commands tell CADDS to log messages to a temporary file, generate the part, and exit.

After CADDS has finished, the program releases the semaphore so that another child can continue. It then reads the log looking for a message saying that the part was created successfully. If the part was created, the script sets the proper permissions on the part. Finally, it reports success or failure to the calling program and exits.

Last Modified: Wed Aug 28 14:41:29 EDT 1996