[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues holding up 1.6.0 release.
From: |
Gary Houston |
Subject: |
Re: Issues holding up 1.6.0 release. |
Date: |
19 Sep 2001 23:09:05 -0000 |
> From: Rob Browning <address@hidden>
> Date: Tue, 18 Sep 2001 08:36:00 -0500
>
> Right now, I'm waiting on someone to tell me what I should do about
> scm_call_with_dynamic_root. I don't feel like that's a decision I
> should make on my own, unless people indicate they want me to. In
> particular:
>
> - should we create the new function that doesn't (re/un)wind the
> dynamic-wind stack?
>
> - should this function go into 1.5.3, or should apps like guppi,
> scwm, and possibly gnucash just continue to copy-paste from root.c
> for the next release?
>
> - I think we already know what the function should look like, but
> what should the new function be named, and should it show up on
> the scm side, or just the C side?
Here's a test implementation of the "new function" idea. I'm not sure
if this would be enough for Guppi, the stack/backtrace issues need
checking.
static void
before (void *unused)
{
SCM_SEQ (scm_rootcont) = ++n_dynamic_roots;
}
static void
after (void *v_oldseq)
{
SCM_SEQ (scm_rootcont) = *(unsigned long *) v_oldseq;
}
SCM
scm_c_with_continuation_barrier (scm_t_catch_body body, void *body_data)
{
unsigned long old_seq = SCM_SEQ (scm_rootcont);
return scm_internal_dynamic_wind (before, body, after, body_data, &old_seq);
}
Optional extras for a Scheme interface:
static SCM
wcb_body (void *v_thunk)
{
return scm_apply (*(SCM *) v_thunk, SCM_EOL, SCM_EOL);
}
SCM_DEFINE (scm_with_continuation_barrier, "with-continuation-barrier",
1, 0, 0,
(SCM thunk),
"Evalutate @var{thunk} ..."
#define FUNC_NAME s_scm_with_continuation_barrier
{
return scm_c_with_continuation_barrier (wcb_body, &thunk);
}
#undef FUNC_NAME