[Top][All Lists]
[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