home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / tcl / 1804 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.2 KB  |  76 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!eco.twg.com!twg.com!news
  3. From: "David Herron" <david@twg.com>
  4. Subject: Re: Dumping/Restoring Interpreter Memory
  5. Message-ID: <1992Nov12.010420.4752@twg.com>
  6. Sensitivity: Personal
  7. Encoding:  56 TEXT , 4 TEXT 
  8. Sender: news@twg.com (USENET News System)
  9. Conversion: Prohibited
  10. Organization: The Wollongong Group, Inc., Palo Alto, CA
  11. Conversion-With-Loss: Prohibited
  12. Date: Thu, 12 Nov 1992 01:08:07 GMT
  13. Lines: 61
  14.  
  15. I've been looking at interpretOR internals lately, sooo...
  16.  
  17.  
  18. > I have noted that the tclTest program has a function call to
  19. > Tcl_DumpActiveMemory, but can't seem to locate this function (John, is this
  20. > not included in the regular distribution?).
  21.  
  22. Isn't that just part of the malloc-checking part of TCL?
  23.  
  24. > This may sound like an odd request, but I was wondering if anyone has devised
  25. > a method for dumping interpreter memory to a file, the restoring this file
  26. > back into an interpreter and continuing processing right where the dump
  27. > left off.
  28.  
  29. Hmm.. an interesting feature here.  But some problems depending on how
  30. much you were interested in saving away.  I wonder (rhetorically) whether
  31. it is of a general enough value that `everyone' would want this feature?
  32.  
  33. Like you suggest one could step through the hash tables and write
  34. out everything you see in some interesting format.  A lot of it
  35. will be variables, arrays and TCL procedures.  Those could be dumped
  36. out as a TCL script and read back in at any time w/o problem.
  37.  
  38. The commands are another problem entirely.  Their entry in the
  39. hash table contains a couple of pointers.  One is to the function
  40. which is to handle the call.  This shouldn't change unless the
  41. program is recompiled.  I don't know if dynamically loadable libraries
  42. will make function addresses change, but very few people are using
  43. dynamically loaded libraries in TCL anyway (which is a pity by itself).
  44.  
  45. The other is programmer-specified data (the clientData argument) which
  46. will almost certainly change between runs of the program and is an
  47. opaque pointer which TCL hasn't the foggiest idea of how to duplicate.
  48. TK Widgets, for instance, put the Tcl_Interp pointer there.  The constant
  49. module I posted a few days ago put a strdup() of the value there.  In my
  50. interp module, the interpInfo structure is passed around in the clientData.
  51.  
  52. This last is, IMO, the killer.
  53.  
  54. If you want to investigate further:
  55.  
  56. the code behind Tcl_CreateCommand() shows how commands are
  57. entered in the hash table.
  58.  
  59. the code which handles the `proc' command shows how procedures
  60. are entered in the hash table.
  61.  
  62. The code behind Tcl_SetVar2() shows how variables are entered
  63. in the hash table.
  64.  
  65. Oh yeah.. another piece of state to save is the function(s) being
  66. executed & the TCL stack.  This is something I haven't looked
  67. at closely, but a fair bit of data seems to be recorded in
  68. the argument lists & local variables of functions all through
  69. the TCL library.  Some data is recorded in the interpretOR
  70. structure ...  Tcl_Eval() will give clues on this.
  71.  
  72. <- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
  73. <-
  74. <- During the '80s Usenet's mantra was: "Not all the world's a VAX".
  75. <- During the '90s I hope it becomes:   "Not all the world's DOS (ick)".
  76.