guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stack unwinding for C code


From: Neil Jerram
Subject: Re: Stack unwinding for C code
Date: 29 Dec 2003 23:25:33 +0000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Marius" == Marius Vollmer <address@hidden> writes:

    Marius> Neil Jerram <address@hidden> writes:
    >> This looks nice - I'll take your word for it that we need this, and
    >> the API looks clean as you say.

    Marius> Don't you think we need it?  Maybe I'm overlooking some obvious
    Marius> alternative that would work just as well...

Sorry - I didn't mean that at all.  I meant only that I hadn't
bothered to think so carefully about the requirement as about your
proposal to meet it.  I am happy that this is a real requirement.

    >> In API terms, this feels to me like the same area as issues like
    >> SCM_DEFER_INTS, control of signal delivery, inhibiting thread
    >> switching, etc.  I realize that these are quite different mechanisms
    >> really, but it would be lovely if the API that you are proposing here
    >> could also cope with and document all those other areas once and for
    >> all.

    Marius> Hmm.  I had to change the continuation stuff already: just 
disallowing
    Marius> all construction and invocation of continuations is too restricitve:
    Marius> continuations that are only used below the frame cause no harm.  
Only
    Marius> continuations that cause the frame to be rewound need to be 
prevented.
    Marius> This is too restrictive as well, in a sense, since continuations 
that
    Marius> are only used in a suspend/resume way (for threads or coroutines, 
say)
    Marius> are OK as well.  But the general continuations are too general to 
know
    Marius> how they are going to be used, so throwing an error when such a 
frame
    Marius> is rewound is all we can do.

This all sounds fine, but I think doesn't address the point that I was
trying to make.  My point was that it might be nice to extend your
proposed API so that it could cover the other tricky points in writing
Guile C code, some of which I listed above.

    >> Perhaps "continuation-proof" or "continuation-protected"?

    Marius> What about "rewindable"?

Yes!  "rewindable" is excellent.

    Marius> (I think that ultimately, we should have a different way of 
reporting
    Marius> error from C code: we should not include the subr name in the call 
to
    Marius> the error reporting function but rather rely on a more general
    Marius> mechanism for providing a backtrace for C code.  I found it 
attractive
    Marius> to just combine it with the frame stuff, but it probably is too
    Marius> early...)

You're probably right, but to be sure I suspect we need more
experiences from users using Guile's debugging tools first.  I doubt
it's worth playing with this until we know more about what is really
useful.

    Marius> - C Function: void scm_c_define_proc (const char *name,
    Marius> int req, int opt,
    Marius> int restp,
    Marius> SCM (*proc) (...))
    >> 
    >> This is not a good name: it is not helpful to suggest that "proc" =
    >> "framed gsubr".  How about scm_c_define_framed_gsubr ?

    Marius> Hmm.  That is so technical.  I wanted to imply that 
scm_c_define_proc
    Marius> is the usual way to export C procedures to Scheme.  Even if you 
don't
    Marius> explicitly ;) ask for a frame, you still get it since it is good for
    Marius> you....

    Marius> But, yeah, I'm removing this together with the label stuff.

I don't understand.  It could still be useful for C procedures to be
non-rewindable by default, even if there isn't a label associated with
the framing.  Do you think there is existing C code that uses
scm_c_define_gsubr and uses rewindability, such that we couldn't just
change scm_c_define_gsubr to enforce non-rewindability?

Hoping these comments help ...

        Neil





reply via email to

[Prev in Thread] Current Thread [Next in Thread]