Linas Vepstas <[email protected]> writes:
> Perhaps I'm naive, perhaps some naming convention
> could be used to indicate that SCM_OUT_OF_RANGE
> will never return? None of the functions in the call stack
> gave any real hint that they might now return; they mostly
> looked liked ordinary functions.
As Andy has said, this kind of thing is quite pervasive in Guile, and
so I think it's something that developers become used to very quickly.
(Incidentally, it happens in your define-race code too. The first
time that the program hits an undefined variable, the error (from
within scm_c_eval_string) causes a jump back out to scm_with_guile.
For the thread concerned, therefore, s->count is never incremented
anymore, and the thread just keeps hitting the same undefined variable
over and over again...)
In this code (scm_sigaction_for_thread) it would probably be better to
use the scm_dynwind_* API, and in particular
scm_dynwind_critical_section, as that would cover the mainline case
and all the error cases in one go. But I'm surprised to see
scm_dynwind_critical_section using a fat mutex; need to look into that
a bit more...
Regards,
Neil
