This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Signal Handling in Guile
- To: NIIBE Yutaka <gniibe at chroot dot org>
- Subject: Re: Signal Handling in Guile
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 13 Mar 2000 10:50:43 +0100
- Cc: guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <200003130940.SAA19820@pwd.chroot.org>
NIIBE Yutaka <gniibe@chroot.org> writes:
> In the current implementation of Guile, signal handler may be called
> at ALLOW_INTS(s), which are scattered around in the code. The
> sequence is:
>
> ALLOW_INTS --> scm_async_click --> the handler
>
> This design complicates the requirement to the extension, while it
> also complicates the implementation itself. Frankly speaking, I don't
> think Guile is bug-less around those area. :-)
>
> Before introducing threads support (Finaly, I've done copyright paper
> work!), I think that we need to change the signal handling design.
> It's not MT issue per se, but without changing this, it results many
> races, and/or dead locks.
>
> How about defining "fixed point" (or points) where it calls
> scm_async_click? Possibly, it could be in scm_ceval or scm_gc.
>
> The design change is: handle signal synchronously.
>
> This will become big changes, I know, but I believe that it's really
> needed for better Guile.
>
> Thought?
In a way, signals are actually handled synchronously. What you're
talking about is restricting the points of synchronization.
The minimal points of synchronization is everywhere where Guile can
enter loops (since these must be interruptible).
What about, then, to restrict the synchronization points to the
occurences of SCM_TICK, i.e. at the top of SCM_CEVAL and in
scm_equal_p?