This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
First, I want to say thanks for the feedback I got for my "Portability and more..." questions, and related to these responses I have more question/observations! First, after reviewing the archive of mailings concerning using guile in a threaded environment I think I understand the issues involved with the conservative gc scheme, which leads to me to ask, is anyone working on alternative methods, similar to elk (elk has selectable gc methods at compile time)? This is of real concern to me because I want to use guile within a cooperative threading environment in which I have no access to the underlying details (such as the call stack of each individual thread), and I can't diddle with the source code. Second, what I would *really* like to do is to give each thread its own instance of a guile interpreter, but unfortunately it does not seem that guile supports the concept of an interpreter context (similar to what TCL has). Now, in the current release of the threading library I am using (Sybase Open Server), there are hookpoints that I can use to, say, swap out name spaces within the interpreter between context switches, but in the upcoming releases, native threading (real honost-to-god lwp's) are supported so this won't work any more since there will be muliple simultaneous name spaces). Any suggestions, or do I just need to live with a shared name space--assuming that I can solve the first problem, above. Thanks again! -scott -- Scott C. Gray gray@voicenet.com "my keybard is brken" Sybase Professional Services scott.gray@sybase.com http://www.voicenet.com/~gray/sqsh.html