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] |
Aleksandar Bakic <bakicale@cps.msu.edu> writes: > Could the stack checking in GUILE be extended to work with C/C++ > (OS) threads? For example, I have a thread that checks X/Tk events and > calls callbacks that invoke GUILE's eval, which in turn reports stack > overflow. I don't understand the question. What does "[stack checking] work with C/C++ (OS) threads" mean? Let me ask a few questions myself: Q: Does Guile work with OS threads? A: No. Currently, Guile only works with its own cooperative threads. If you initialize Guile from one OS thread and then call Guile from another, it is likely that Guile will report a stack overflow since the stackpointer will be checked against the stack of the OS thread which initialized Guile. Furthermore, it is likely that Guile will crash, mainly because: 1. the garbage collector won't find heap pointers on the second thread's stack, and 2. Guile does not currently support preemptive threading, so any data structures common to the threads (such as the list of free cells!) will pretty soon be messed up. Q: Can Guile be extended to work with OS threads? A: Yes, but it is a fair amount of work to do so. Almost the whole library needs to be looked over. This will probably done, but currently there are higher priority tasks. Q: Meanwhile, could we modify stack checking so that it works for two OS threads accessing the library? A: Yes, but due to the answer to the first question, I don't see the point. > I tried to change the value of scm_stack_checking_enabled_p > in my code (actually, only before scm_boot_guile or in "inner_main") > but it didn't work. scm_stack_checking_enabled_p is an internal flag which is used to disable stack checking in certain code segments (such as reporting a stack overflow error). You shouldn't touch this flag. > I had to comment out a couple of lines in __scm.h to disable stack > checking. The user interface to stack checking is the debug options interface. If you type `(debug-options 'full)' you get current values and documentation for the different options. For stack checking you have: stack 20000 Stack size limit (0 = no check). which means that you can disable stack checking with (debug-set! stack 0) Best regards, /mdj