mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-06 23:50:18 +02:00
* extension/dynamic-root.text: example Scheme code.
This commit is contained in:
Gary Houston
parent
edb810bb84
commit
ba040a71a0
2 changed files with 0 additions and 170 deletions
|
|
@ -1,84 +0,0 @@
|
||||||
2002-02-05 Thien-Thi Nguyen <ttn@giblet.glug.org>
|
|
||||||
|
|
||||||
* build/pre-inst-guile.text: Initial revision.
|
|
||||||
|
|
||||||
2001-12-04 Gary Houston <ghouston@arglist.com>
|
|
||||||
|
|
||||||
* some discussion in extension/dynamic-root.text.
|
|
||||||
|
|
||||||
2001-11-28 Gary Houston <ghouston@arglist.com>
|
|
||||||
|
|
||||||
* added extension directory and extension/dynamic-root.text with
|
|
||||||
a description of the problem.
|
|
||||||
|
|
||||||
2001-11-14 Thien-Thi Nguyen <ttn@giblet.glug.org>
|
|
||||||
|
|
||||||
* policy/api.text: Initial revision.
|
|
||||||
|
|
||||||
2001-11-12 mvo <mvo@giblet.glug.org>
|
|
||||||
|
|
||||||
* translation/lisp-and-scheme.text:
|
|
||||||
*** empty log message ***
|
|
||||||
|
|
||||||
2001-07-07 mvo <mvo@giblet.glug.org>
|
|
||||||
|
|
||||||
* policy/goals.text: Sneak in the translators...
|
|
||||||
|
|
||||||
2001-06-27 Thien-Thi Nguyen <ttn@revel.glug.org>
|
|
||||||
|
|
||||||
* README: Remove tasks.text.
|
|
||||||
|
|
||||||
* tasks.text: Bye bye (contents folded into ../TODO).
|
|
||||||
|
|
||||||
2001-05-08 Martin Grabmueller <mgrabmue@cs.tu-berlin.de>
|
|
||||||
|
|
||||||
* modules/module-snippets.texi: Fixed a lot of typos and clarified
|
|
||||||
some points. Thanks to Neil for the typo+questions patch!
|
|
||||||
|
|
||||||
2001-05-07 Martin Grabmueller <mgrabmue@cs.tu-berlin.de>
|
|
||||||
|
|
||||||
* modules/module-snippets.texi: New file, documenting the module
|
|
||||||
system. Placed in `devel' for review purposes.
|
|
||||||
|
|
||||||
2001-03-16 Martin Grabmueller <mgrabmue@cs.tu-berlin.de>
|
|
||||||
|
|
||||||
* modules: New directory.
|
|
||||||
|
|
||||||
* modules/module-layout.text: New file.
|
|
||||||
|
|
||||||
2000-08-26 Mikael Djurfeldt <mdj@linnaeus.mit.edu>
|
|
||||||
|
|
||||||
* strings: New directory.
|
|
||||||
|
|
||||||
* strings/sharedstr.text (sharedstr.text): New file.
|
|
||||||
|
|
||||||
2000-08-12 Mikael Djurfeldt <mdj@linnaeus.mit.edu>
|
|
||||||
|
|
||||||
* translate: New directory.
|
|
||||||
|
|
||||||
* translate/langtools.text: New file.
|
|
||||||
|
|
||||||
2000-05-30 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* tasks.text: Use outline-mode. Added section for tasks in need
|
|
||||||
of attention.
|
|
||||||
|
|
||||||
2000-05-29 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* tasks.text: New file.
|
|
||||||
|
|
||||||
2000-05-25 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* README: New file.
|
|
||||||
|
|
||||||
* build/snarf-macros.text: New file.
|
|
||||||
|
|
||||||
2000-05-20 Mikael Djurfeldt <mdj@mdj.nada.kth.se>
|
|
||||||
|
|
||||||
* policy/goals.text, policy/principles.text, policy/plans.text:
|
|
||||||
New files.
|
|
||||||
|
|
||||||
2000-03-21 Mikael Djurfeldt <mdj@thalamus.nada.kth.se>
|
|
||||||
|
|
||||||
* policy/names.text: New file.
|
|
||||||
|
|
||||||
|
|
@ -1,86 +0,0 @@
|
||||||
The Problem
|
|
||||||
===========
|
|
||||||
|
|
||||||
Certain applications embedding Guile (Scwm, Guppi) have found it
|
|
||||||
necessary to include hacked versions of scm_call_with_dynamic_root.
|
|
||||||
|
|
||||||
They want to run user callbacks, but don't want the callback to be
|
|
||||||
able to longjmp (via exceptions or continuations) randomly in and out,
|
|
||||||
since the C code hasn't been written to dynamically wind/unwind local
|
|
||||||
state. This is likely to be a common problem for users of Guile as an
|
|
||||||
extension language.
|
|
||||||
|
|
||||||
libguile/root.c:scm_call_with_dynamic_root seems to almost do this,
|
|
||||||
but it has the apparently undesirable behaviour of unwinding the
|
|
||||||
dynamic state when the protected procedure is called. In addition
|
|
||||||
the implementation looks a bit heavy for use in every callback.
|
|
||||||
|
|
||||||
scm_call_with_dynamic_root was implemented to support threading, so
|
|
||||||
the needs of libguile itself should be considered. Other
|
|
||||||
considerations are how any new interface interacts with error handling
|
|
||||||
and reporting; whether a new interface is convenient to use from C;
|
|
||||||
whether a new interface should also be available to Scheme code.
|
|
||||||
|
|
||||||
Discussion
|
|
||||||
==========
|
|
||||||
|
|
||||||
There are two ways that longjmp may be invoked from a Scheme callback:
|
|
||||||
raising an exception or invoking a continuation. Exceptions can be
|
|
||||||
caught using scm_internal_catch, so it could be argued that the new
|
|
||||||
interface only needs to block continuations.
|
|
||||||
|
|
||||||
However there are two problems with this: firstly it's unlikely that
|
|
||||||
anybody would want to block continuations without also catching
|
|
||||||
exceptions, so it's more convenient to use a single facility set up
|
|
||||||
both types of blocking. Secondly, the fact that exceptions and
|
|
||||||
continuations can be treated separately in Guile is just an
|
|
||||||
implementation detail: in general in Scheme it's possible to use
|
|
||||||
continuations to implement an exception mechanism, and it's
|
|
||||||
undesirable to tie a new language feature to an implementation detail
|
|
||||||
when it can be avoided, even at the C level.
|
|
||||||
|
|
||||||
Hence, the interface should take at least a) the callback to be
|
|
||||||
protected b) and exception handler and associated handler data to be
|
|
||||||
passed to scm_internal_catch.
|
|
||||||
|
|
||||||
On which side of the continuation barrier should be exception handler
|
|
||||||
be installed? Logically it belongs on the same side as the callback:
|
|
||||||
i.e., if the callback raises an exception then the handler can catch
|
|
||||||
it without crossing it the continuation barrier. But what happens if
|
|
||||||
the handler raises another exception? This doesn't seem like an
|
|
||||||
important concern, since the hander is under control of the code that
|
|
||||||
is trying to protect itself. It should be sufficient to warn in the
|
|
||||||
documentation that such exceptions produce undefined behaviour and
|
|
||||||
allow them to cross the continuation barrier.
|
|
||||||
|
|
||||||
How should the callback procedure be passed to the interface and
|
|
||||||
invoked? Should it be like scm_internal_catch where it's passed as a
|
|
||||||
C procedure (scm_t_catch_body) which is applied to user data (void *)?
|
|
||||||
For a procedure designed to be used from C, this is the most
|
|
||||||
convenient, since constructing closures in C is difficult. It also
|
|
||||||
gives symmetry with scm_internal_catch.
|
|
||||||
|
|
||||||
On the other hand, the body procedure is expected to be a Scheme
|
|
||||||
closure in most cases. This suggests implementing two C procedures,
|
|
||||||
the first taking four arguments:
|
|
||||||
|
|
||||||
scm_t_catch_body body, void *body_data,
|
|
||||||
scm_t_catch_handler handler, void *handler_data
|
|
||||||
|
|
||||||
and the second taking three arguments:
|
|
||||||
SCM body, scm_t_catch_handler handler, void *handler_data
|
|
||||||
|
|
||||||
If there is also to be a Scheme interface, then it would be implemented
|
|
||||||
with a third variant:
|
|
||||||
SCM body, SCM handler
|
|
||||||
|
|
||||||
The second and third variants would be implemented by calling the
|
|
||||||
first, similar to the old scm_call_with_dynamic_root and its wrappers.
|
|
||||||
|
|
||||||
The return value from all variants should be the result of calling
|
|
||||||
the body, unless an exception occurred in which case it's the result
|
|
||||||
of calling the handler. So the return type is SCM, as for
|
|
||||||
scm_internal_catch.
|
|
||||||
|
|
||||||
Yet to be discussed: libguile usage and threads, error handling and
|
|
||||||
reporting, convenience of use, Scheme-level interface.
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue