From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f4fd2,23202754c9ce78dd X-Google-Attributes: gidf4fd2,public X-Google-Thread: fac41,15edb893ef79e231 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,15edb893ef79e231 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,15edb893ef79e231 X-Google-Attributes: gid114809,public X-Google-ArrivalTime: 2002-02-10 23:18:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!intermedia!panix!not-for-mail From: dkcombs@panix.com (David Combs) Newsgroups: comp.lang.lisp,comp.lang.ada,comp.lang.eiffel,comp.lang.smalltalk Subject: Re: True faiths ( was Re: The true faith ) Date: 11 Feb 2002 07:18:01 GMT Organization: Public Access Networks Message-ID: References: <3C4DE336.3080102@worldnet.att.net> NNTP-Posting-Host: panix3.panix.com X-Trace: news.panix.com 1013411881 623 166.84.1.3 (11 Feb 2002 07:18:01 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: 11 Feb 2002 07:18:01 GMT X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: dkcombs@panix.com (David Combs) Xref: archiver1.google.com comp.lang.lisp:26201 comp.lang.ada:19851 comp.lang.eiffel:5654 comp.lang.smalltalk:19470 Date: 2002-02-11T07:18:01+00:00 List-Id: In article , AG wrote: >> Bruce Hoult wrote: >> >> > Garbage collection has a *lot* to do with this problem! >> > >> > A large proportion of assignments in languages such as C++ are done >> > merely in order to resolve the question of who owns an object and who is >> > responsible for eventually deleting it. >> > >> > With GC available, objects are seldom copied with pointers to them being >> > passed around instead. You don't care who "owns" the object, because it >> > just magically goes away when all the pointers to it get forgotten. > >This doesn't seem to be a question of something "going away", it's a >question >of how the object(s) behave while they are still in use. For example: > >Suppose you have a process A which has something (an object or whatever) >called X it wants to pass to a process B. The process B must be free to do >whatever it wants to/with that X thing. However, the process A also wants to >keep going with the X after the B is done with whatever it was doing Coroutines (across processes) help here? You do have to know (not just when?) but *where*, in the source, you want to "resume" the other one. Not at all "automatic". How *does* one nicely-handle such a situation? "Automatically"? How about this one (maybe simple, obvious, for you guys, but not for me): You're writing a program in a language that has gc, eg lisp (or Mainsail, the language I use -- derived from (ancient) SAIL (Stanford's Algol-like syntaxed competitor to lisp as ai language -- lost, of course), and from one or more places in the program written in the language-with-gc, you want to call out to something written in a *different* language, which also has a *different* memory-mngt scheme -- maybe gc, maybe not. And you want to pass a ref to a data structure owned by the first progtam into the second program. So far, simple enough. The with-gc language is stopped between the call into the other-languaged program and the return back in. No problem with a gc occurring *while* the 2nd program is playing with the (shared) data structure. HOWEVER -- suppose that that called 2nd-program needs to call a function back in the 1st program. NOW we DO have a problem: that call back into the first program, the one with memory-mngt via gc, just might eat up enough pieces of newly allocated memory that it triggers a gc! Thus pulling the rug out from under the 2nd program -- since its reference back into the first program's data structure will be pointing to garbage, if the "shared" data structure gets slid somewhere else by the gc. QUESTION: what kind of solutions are there to this problem? (The one I've been using is to turn off the gc during the first call out, and re-activating it when that first call returns -- the hope being that the 2nd call back in doesn't run out of memory! (Actually, we make it do a preemptive gc before we freeze everything.) So far, so good....) What are some more, er, robust approaches? Thanks! David