2009/1/17 Linas Vepstas <linasveps...@gmail.com>: > 2009/1/16 <dsm...@roadrunner.com>: >> ---- Neil Jerram <neiljer...@googlemail.com> wrote: >>> scm_init_guile has always been a bit problematic, as it requires lots >>> of heuristic and OS-dependent code to try to determine where the base >>> of the stack is. It's never been formally deprecated, but we have >>> always advised people to use scm_boot_guile or scm_with_guile if they > >> Iirc, scm_init_guile is mainly used when you do not have access to main(), >> for example writing a module for apache. Generally, when you want to add >> Guile to an already existing application that has plugins or extension >> modules via .so's. > > This is an excellent example of where scm_init_guile > is exactly the *wrong* function to use.
I would say that it's not definitely wrong, but it's certainly risky. The point is that "guile mode"-ness applies on a per-thread basis, so scm_init_guile (on its own) can only be correct if you are sure that the application is always going to execute your libguile-using code on the same thread (the one where you called scm_init_guile). > The problem is, > of course, that if you scm_init_guile in some .so, > you will accidentally place the entire system into guile > mode, and not just the .so, as intended. Or, to put that another way, the "guile mode"-ness persists on the thread that called your libguile-using code, even after the thread has returned back into the depths of the application. That might not be a problem, but it could be. For example, threads in guile mode are (currently; I'm not sure what BDW-GC will do) paused when a garbage collection is needed; so activity on another guile thread could suddenly block the application thread; or more likely the other way round: the GC would not be able to proceed, because the application thread would not actually pause. > Instead, you want to call scm_with_guile on entry to > the so, it will unwind on exit. > > This could be cleared up by having the docs make > the case more forcefully. Yes x 2. Neil
