From ... Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!news.tele.dk!128.39.3.166!uninett.no!Norway.EU.net!127.0.0.1!nobody From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: Lisp & C Date: 28 Oct 2000 09:42:09 +0000 Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net Lines: 22 Message-ID: <3181714929335190@naggum.net> References: <39F597AE.F753BF3C@utbm.fr> <39FA032A.168B6967@osu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: oslo-nntp.eunet.no 972728278 10754 195.0.192.66 (28 Oct 2000 10:17:58 GMT) X-Complaints-To: newsmaster@eunet.no NNTP-Posting-Date: 28 Oct 2000 10:17:58 GMT mail-copies-to: never User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Xref: supernews.google.com comp.lang.lisp:2763 * Daniel Kiracofe | I've figured out how to get Lisp/Scheme to interface to my C code, | but my problem is that my C code is multi-threaded. Everything I | found so far generally tends to allocate some global interpreter | state, so it's not reentrant. So, what I need is a Lisp/Scheme | implementation that I can call from C, that is reentrant. Any | suggestions? TIA... Interprocess communication including shared memory and semaphores. I have started on a general package for this several times, but always end up specializing it into oblivion as far as generality and publishability is concerned. I really do _not_ want C code that I don't trust to muck around in the Lisp memory. I also tend to design my own protocols over sockets to make the coupling as loose as possible. (The more common protocols use far too tight coupling for me qua protocols, and not at all tight enough if they pretend to be shared memory across the wire.) #:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush