[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
entering and leaving guile mode, and GC stack protection (was Re: guile
From: |
Ken Raeburn |
Subject: |
entering and leaving guile mode, and GC stack protection (was Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled) |
Date: |
Thu, 6 Aug 2009 12:30:53 -0400 |
On Aug 5, 2009, at 10:06, I wrote:
(3) My four-year-old comments on scm_enter/leave_guile, recorded in
threads.c around line 300, still stand.... Those functions really
ought to go away. At least they're confined to one file, now. Some
of it looks a little messy, but I can probably get rid of some of
the uses....
I've made a bit of progress on this.
The basic issue is that the way scm_enter/leave_guile are implemented,
they make some bad assumptions about how the stack will be laid out
and where SCM values might get stored. The right way to tackle it, I
believe, is to only provide functions like scm_without_guile that make
callbacks, and get complete control over the transitions both into and
out of guile mode so they can better manage the stack layout.
It's not just scm_leave_guile() that needs to go away and be replaced
by a different interface, but suspend() and anything that calls it
without pairing it up nicely with resume(). Functions pairing them up
need updating too, but not their interfaces; the code in between
suspend and resume just needs to be pulled out into a callback function.
So my changes in this first cut are basically:
* New function while_suspended takes callback and replaces
suspend...resume sequence; used only in scm_i_thread_sleep_for_gc now
but scm_without_guile is an obvious additional place, when we can get
rid of scm_leave_guile.
* New helper function scm_without_guile_int, like scm_without_guile
but return type is int. Static for now; would it be useful to export?
* Replace scm_i_thread_put_to_sleep and _wake_up with
scm_i_with_threads_sleeping which takes a callback. Change
resize_all_states, scm_i_gc, scm_i_string_writable_chars accordingly.
* Use scm_without_guile(_int) in scm_std_select,
scm_pthread_mutex_lock (assumes my earlier change!),
scm_pthread_cond_wait, scm_pthread_cond_timedwait,
scm_i_with_threads_sleeping.
There are still unpaired uses of scm_leave_guile and scm_enter_guile
that I'm going to have to look at more closely before I can figure out
what to do about them. And the problematic suspend() function itself
is still there, but once its usage is confined to while_suspended,
it'll be easier to clean up.
Comments?
Ken
guile-patch.diff
Description: Binary data
- guile performance - Ackermann function: way slower than emacs, slower still if compiled, Ken Raeburn, 2009/08/04
- Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Marijn Schouten (hkBst), 2009/08/04
- Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Andy Wingo, 2009/08/05
- Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Ken Raeburn, 2009/08/05
- entering and leaving guile mode, and GC stack protection (was Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled),
Ken Raeburn <=
- Re: entering and leaving guile mode, and GC stack protection, Andy Wingo, 2009/08/12
- Re: entering and leaving guile mode, and GC stack protection, Ludovic Courtès, 2009/08/14
Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Ludovic Courtès, 2009/08/08
Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Andy Wingo, 2009/08/05
Re: guile performance - Ackermann function: way slower than emacs, slower still if compiled, Andy Wingo, 2009/08/05