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: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 13 Mar 2000 11:53:55 +0200
- Cc: guile at sourceware dot cygnus dot com
- Organization: who? me?
- References: <200003130940.SAA19820@pwd.chroot.org>
NIIBE Yutaka <gniibe@chroot.org> writes:
> 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.
to clarify: you want thread switches to happen at those "fixed points"
("safe points" in RScheme-speak) too, right?
this does sound reasonable, considering that Guile doesn't provide any
real-time guarantees anyway.
is your design somewhere online? not that I'm one who decides
anything, but I'm very curious.
> This will become big changes, I know, but I believe that it's really
> needed for better Guile.
why would the changes be big?
--
I have seen the future, and it does not work.