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