From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.user Subject: Re: to serialize/deserialize closures; and multithreading Date: Thu, 25 Mar 2004 13:11:32 -0500 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <406320D4.4030102@indiana.edu> References: <4063144B.8050705@indiana.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1080238324 30639 80.91.224.253 (25 Mar 2004 18:12:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 25 Mar 2004 18:12:04 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Mar 25 19:11:51 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B6ZKZ-00007Z-00 for ; Thu, 25 Mar 2004 19:11:51 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B6ZDn-0005T1-O0 for guile-user@m.gmane.org; Thu, 25 Mar 2004 13:04:51 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B6ZCN-00050v-PD for guile-user@gnu.org; Thu, 25 Mar 2004 13:03:23 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B6ZBp-0004pa-TR for guile-user@gnu.org; Thu, 25 Mar 2004 13:03:21 -0500 Original-Received: from [129.79.1.73] (helo=plounts.uits.indiana.edu) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B6ZBp-0004pL-EE for guile-user@gnu.org; Thu, 25 Mar 2004 13:02:49 -0500 Original-Received: from fontz.uits.indiana.edu (fontz.uits.indiana.edu [129.79.1.76]) by plounts.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id i2PI2fxI017462 for ; Thu, 25 Mar 2004 13:02:41 -0500 (EST) Original-Received: from indiana.edu (dial-123-114.dial.indiana.edu [156.56.123.114]) (authenticated bits=0) by fontz.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id i2PI2a4w006209 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 25 Mar 2004 13:02:40 -0500 (EST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en Original-To: guile-user@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:2996 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:2996 On the other hand, you could just rely on guile's printer/reader syntax and use that on the environment to export it and the global variables. I don't know if it prints everything in a uniquely readable way, but it should handle standard scheme that way. And environments in guile (last time I looked at the evaluator) really are just binding lists. With deBruijn indices. I can't remember exactly. Use the source. Lynn Lynn Winebarger wrote: > It's an interesting question all right. What's the purpose of the > "migration"? > Technically speaking, a closure is just a pair of pointers to its > code and > its environment. You could create a new "foreign reference" type (tag) > that > would cause these to be looked up on the original computer whenever you > needed > them. That would handle synchronization. Of course, you could also > make copies > of everything. I think tags are constant over all architechtures (last > I looked) > but there are run-time allocated types that you'd have to do some work for > (I think - I don't remember what they're called). > Anyway, besides taking care of the tags/synchronizing run-time > allocated types/ > handling endianness issues, you'd need to munge pointers according to > whereever > they would be newly allocated on the new machine. It would probably be > easiest > to just number copies of the cells from 0 to whatever for the transport > over and the > allocator on the other end could relabel them to the actual values. > Also, you'd need to check that any symbols referenced by the code or > variables were > actually in existence in the new guile instance's symbol table. And > that global > variables referenced by the code got copied (as well as the lexical > variables). > So will be recursively nasty. > > Good Luck. > > Lynn > > Greg Troxel wrote: > >> 1. If I have a scheme value that is a closure, is there any way that >> I can >> serialize this closure (from C code) into a form that it can be >> deserialized back into a SCM closure variable (again, by C code)? I >> can >> assume for this question that both ends of the serial line are >> running the >> same version of gnu guile and my software, but cannot assume that both >> ends are running on the same computer architecture. Would it instead >> only be possible for me to transfer closures as their scheme source. >> >> I'm not even sure it is well-defined what it means to migrate a >> closure. Should a mutation on the new computer of a captured variable >> affect the old computer? >> > > > > > _______________________________________________ > Guile-user mailing list > Guile-user@gnu.org > http://mail.gnu.org/mailman/listinfo/guile-user > > > _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user