[gambit-list] Graceful shutdown of running gambit process

François Magnan francois.magnan at licef.ca
Tue Apr 22 16:08:03 EDT 2008


Hi,

It would be nice if such a hook could be created on all Gambit  
platforms. In the meantime, I would simply suggest that you make your  
persistency code more robust (with transactions for example). Just an  
idea...

Francois Magnan



On 22-Apr-08, at 3:47 PM, Bradley Lucier wrote:

> 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
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list