Didier> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Didier> and seems to be usable in multi-threaded apps. Didier> In Elk, the garbadge collector acts ala emacs: you inform it Didier> explicitely of any objects that should be protected with GC_Link(). Even if Didier> it's a PITA to have to protect by hand the scheme objects, the advantage is Didier> that different threads can create and protect scheme objects easily. On the Didier> contrary, there's no explicit GC protection in guile. Consequently, guile will Didier> know only the main program stack and objects created by subsequent threads Didier> won't be caugth by the GC. You really need to say what you mean by "thread." If you mean threads of the underlying C library or the OS, then the GC protection mechanism doesn't help you much, because it's not thread-safe itself. It doesn't perform any synchronization whatsoever. If you're talking about threads as provided Elk---well, there aren't any. Didier> Does this mean that I can't safely have different threads calling Didier> scheme functions in parallel, even if those functions don't use or affect Didier> global objects ? Again, specify what you mean by "thread" and I'll give you an answer. Unless I'm missing something in your question, the answer is always "no," however. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla