This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Signal Handling in Guile


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]