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
can, and the manual says:
The function `scm_init_guile' might not be available on all
platforms since it requires some stack-bounds-finding magic that
might not have been ported to all platforms that Guile runs on.
Thus, if you can, it is better to use `scm_with_guile' or its
variation `scm_boot_guile' instead of this function.
Now I've found another problem with it (while investigating Greg's
NetBSD "unlocking unlocked mutex" report), so I'm wondering if it's
time now (i.e. in Guile 2.0) to remove it. Can you respond to this
thread if you think you would be inconvenienced by this, or are aware
of a library or application that currently uses scm_init_guile ?
The problem is that if a thread is initialized (for Guile) by calling
scm_init_guile, Guile doesn't push a cleanup function for it. This
means that if that thread is later terminated while in Guile mode, it
will die holding its "heap" mutex, and sooner or later (at the next
GC) that will cause all other Guile processing to hang. It isn't
possible for scm_init_guile to push a cleanup function, because the
pthreads API requires pthread_cleanup_push () and pthread_cleanup_pop
() to be paired in the same lexical scope.
Thoughts? On the other hand, does moving to BDW-GC take a lot of this
out of our hands anyway? In any case, it would be interesting to hear
whether people think that scm_init_guile is really needed.
Regards,
Neil
