holds the remnant of coldtcl, which hasn't been worked on for years.One such is ColdtclPurpose:If you have a large enough persistent process, you don't really need external storage. Per-process VM size is around 2Gb.So, you don't need a db, you can just store stuff in tcl data types.
Coldtcl - tcl workspace- Colin McCormack <coldstore at users dot sf dot net> 30/05/2004Coldtcl makes tcl 8.5 (and earlier) checkpointable. Runs under Linux, YMMV. It's based on my work on ColdStore.Run it using ./coldtcl and you'll get a tclsh in all respects identical to your usual.It provides a single command - [suspend] which writes the complete running state of tclsh to disk in a file called coldtcl.store containing all current state of the tclsh.A subsequent invocation of coldtcl will load coldtcl.store and restart with the entire tclsh state restored exactly as it was when [suspend] was called.The only complication is open files. It is necessary to close all open files in any interpreter under {} before calling [suspend], not doing so will cause unpredictable results ... I doubt you'll enjoy them. The exceptions are stdin, stdout and stderr, which are recreated anew on every invocation.If your workspace calls exit (for example as a result of an error,) you'll be left with an unusable store. It's probably a good idea, therefore, to modify exit accordingly. I'll come up with a simple example, if people need it.There's always the possibility that coldtcl leaks memory ... I can't be sure yet.There's not a chance it'll suspend and resume multiple threads. It might work if you shut down all but the original thread, I don't know. Quite possible.coldtcl depends upon mmalloc, which is GPL'd, it is therefore, perforce, also GPL'd.Performance:Coldtcl uses an mmap malloc to write its per-process swap to a file. This means it'll run as fast as normal tclsh, there should be no real difference to the usual tclsh.
This delights CL, who hopes to write more about it in the future.
See also:
