From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.43.194.69!fr.clara.net!heighliner.fr.clara.net!hamster.europeonline.net!newsfeed.europeonline.net!nmaster.kpnqwest.net!nreader3.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Question: Lisp's power points References: <3bc55443_3@corp-goliath.newsgroups.com> <3211824385979077@naggum.net> <3BC7156C.CAB20E31@ilt.fhg.de> <3211913788516770@naggum.net> <3BC82585.1D716F91@t-online.de> <3211980215750828@naggum.net> <3bc93d54.741721509@news.callatg.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3212085346119781@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 45 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Oct 2001 21:55:46 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader3.kpnqwest.net 1003096546 193.90.206.17 (Sun, 14 Oct 2001 23:55:46 MET DST) NNTP-Posting-Date: Sun, 14 Oct 2001 23:55:46 MET DST Xref: archiver1.google.com comp.lang.lisp:17812 * Roger Corman | I just want to make a comment here. Common Lisp does not specify how | special variables interact with threads, so this is an area that is | debatable. This is true, but extending the concept of special binding to threads is not a conceptual hurdle, it is more of an implementational hurdle. | In my opinion an optimal implementation of per-thread special variable | bindings does not require any re-binding. I was unspecific. The design I had mind was threads managed by a single, monolithic process, but I did cover the case of separate processes, as well, those needing IPC and shared memory. I.e., the process scheduler in the Common Lisp system, not the kernel, would have to do a context switch that would include saving and restoring the binding stack of the new context. This is one of the drawbacks of having your own scheduler, but there are also serious drawbacks to using operating system threads and processes, especially when using shared memory for all the global _objects_, and that includes code. | And if all those threads are active at once, no problem. No context | switching need occur. Well, context switching between threads at the operating system level is different from context switching between threads when privately managed. | I can't see a reason for a thread to re-bind it, and then have all other | threads see the binding. That was clearly not what I wanted to say, either. | I think you would have multiple threads trying to undo each others | bindings, possibly. Only if you assume a globally shared memory and operating system threads. I find it fascinating that you only consider those kinds of threads and not the well-known technique of managing multiprocessing privately. /// -- The United Nations before and after the leadership of Kofi Annan are two very different organizations. The "before" United Nations did not deserve much credit and certainly not a Nobel peace prize. The "after" United Nations equally certainly does. I applaud the Nobel committee's choice.