Re: Locks and threads

[Neil Jerram <neil@ossau.uklinux.net>]

Linas Vepstas <linasvepstas@gmail.com> 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