when it is exited non-locally. Likewise, the port needs to be set again
when control enters non-locally.
-Scheme code can use the @code{dynamic-wind} function to arrange for the
-setting and resetting of the global state. C code could use the
-corresponding @code{scm_internal_dynamic_wind} function, but it might
-prefer to use the @dfn{frames} concept that is more natural for C code,
-(@pxref{Frames}).
+Scheme code can use the @code{dynamic-wind} function to arrange for
+the setting and resetting of the global state. C code can use the
+corresponding @code{scm_internal_dynamic_wind} function, or a
+@code{scm_dynwind_begin}/@code{scm_dynwind_end} pair together with
+suitable 'dynwind actions' (@pxref{Dynamic Wind}).
Instead of coping with non-local control flow, you can also prevent it
by erecting a @emph{continuation barrier}, @xref{Continuation
do such a thing on its own.
If you do not want to allow the running of asynchronous signal handlers,
-you can block them temporarily with @code{scm_frame_block_asyncs}, for
+you can block them temporarily with @code{scm_dynwind_block_asyncs}, for
example. See @xref{System asyncs}.
Since signal handling in Guile relies on safe points, you need to make
guile mode for the first time, it gets a Scheme representation and is
listed by @code{all-threads}, for example.
-While in guile mode, a thread promises to reach a safe point reasonably
-frequently (@pxref{Asynchronous Signals}). In addition to running
-signal handlers, these points are also potential rendezvous points of
-all guile mode threads where Guile can orchestrate global things like
-garbage collection. Consequently, when a thread in guile mode blocks
-and does no longer frequent safe points, it might cause all other guile
-mode threads to block as well. To prevent this from happening, a guile
-mode thread should either only block in libguile functions (who know how
-to do it right), or should temporarily leave guile mode with
-@code{scm_without_guile} or
-@code{scm_leave_guile}/@code{scm_enter_guile}.
+While in guile mode, a thread promises to reach a safe point
+reasonably frequently (@pxref{Asynchronous Signals}). In addition to
+running signal handlers, these points are also potential rendezvous
+points of all guile mode threads where Guile can orchestrate global
+things like garbage collection. Consequently, when a thread in guile
+mode blocks and does no longer frequent safe points, it might cause
+all other guile mode threads to block as well. To prevent this from
+happening, a guile mode thread should either only block in libguile
+functions (who know how to do it right), or should temporarily leave
+guile mode with @code{scm_without_guile}.
For some common blocking operations, Guile provides convenience
functions. For example, if you want to lock a pthread mutex while in
risk of the internal data structures of libguile becoming corrupted in
such a way that the process crashes.
-A program might still produce non-sensical results, though. Taking
+A program might still produce nonsensical results, though. Taking
hashtables as an example, Guile guarantees that you can use them from
multiple threads concurrently and a hashtable will always remain a valid
hashtable and Guile will not crash when you access it. It does not
Guile provides two mechanisms to support critical sections as outlined
above. You can either use the macros
@code{SCM_CRITICAL_SECTION_START} and @code{SCM_CRITICAL_SECTION_END}
-for very simple sections; or use a frame together with a call to
-@code{scm_frame_critical_section}.
+for very simple sections; or use a dynwind context together with a
+call to @code{scm_dynwind_critical_section}.
The macros only work reliably for critical sections that are
guaranteed to not cause a non-local exit. They also do not detect an
to libguile functions or to other external functions that might do
complicated things.
-The function @code{scm_frame_critical_section}, on the other hand,
-will correctly deal with non-local exits because it requires a frame.
-Also, by using a separate mutex for each critical section, it can
-detect accidental reentries.
+The function @code{scm_dynwind_critical_section}, on the other hand,
+will correctly deal with non-local exits because it requires a dynwind
+context. Also, by using a separate mutex for each critical section,
+it can detect accidental reentries.
HCoop / bpt / guile.git / blobdiff