[gambit-list] Graceful shutdown of running gambit process
Bradley Lucier
lucier at math.purdue.edu
Tue Apr 22 15:47:00 EDT 2008
Marc:
My homework on the web system needs a way to shut down gracefully.
Perhaps you can recommend how to do this.
I'm using Gambit-C 4.0a8 (yes, that's right, "a8") because it doesn't
have the GC bug that plagues long-running Gambit programs that use
keyword/optional/whatever arguments in more recent versions of Gambit.
The program handles up to 1000 students at a time, with > 800 threads
(one for each concurrent student) running an hour or so before
homework is due ;-). Each Gambit process (there's one application
running for each course) starts up 5 Maple processes as back-end
servers. It uses a very simple method to store student results---
when a student goes from one problem to another or from one problem
set to another, or when a student logs out or is timed out for
inactivity, it uses pretty-print to write the student's current data
to a file, and then uses RCS to archive the difference between the
current version and the previous one.
Especially near the beginning of each semester, students add and drop
the course, and move from one section to another. Currently, I deal
with this by killing the Gambit job and restarting it with the new
student lists, etc. (Each student's data stays with the student, if
the student doesn't pay his/her fees and is temporarily dropped from
the course, all the pre-existing work is still there when the student
is re-registered for the class; if a student moves sections, it only
affects to which instructor a student's grades are e-mailed.) The
restarting is effective, and takes only about 1 minute or two, but
students currently working on the system have to log back into the
system after the system comes back up.
The problem is that about once a semester, the program is killed as a
student's data is pretty-printed to the data file, so the data that
is written is only a truncated list. The next time the program
attempts to load the data, there is an error, mutexes are abandoned,
etc. A day or two goes by before it's really bad enough that someone
informs me there's a problem, and I eventually find the problem,
restore data from the RCS file, and go on our merry way. (To my
knowledge, no student data has ever been lost.)
What I'd like is a way to send a signal to the program to shut down
gracefully---go to each thread, one by one, save the student data,
use RCS to back it up, and when you've done all that exit gracefully
(or now restart by reloading the class lists, etc.). This should
avoid the rare but somewhat catastrophic failures I see when a
student data file is truncated.
So, that's the background; any suggestions?
Brad
More information about the Gambit-list
mailing list