From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack unwinding for C code Date: 29 Dec 2003 23:25:33 +0000 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87y8sz5kio.fsf@zagadka.ping.de> <87ptea40wu.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1072740745 26128 80.91.224.253 (29 Dec 2003 23:32:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 29 Dec 2003 23:32:25 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Dec 30 00:32:21 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ab6s1-0005p7-00 for ; Tue, 30 Dec 2003 00:32:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ab7oj-0002Hn-3x for guile-devel@m.gmane.org; Mon, 29 Dec 2003 19:33:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ab7oC-0002HC-MM for guile-devel@gnu.org; Mon, 29 Dec 2003 19:32:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ab7ng-00029W-2k for guile-devel@gnu.org; Mon, 29 Dec 2003 19:32:27 -0500 Original-Received: from [80.84.72.14] (helo=mail2.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ab7nf-00029B-D3 for guile-devel@gnu.org; Mon, 29 Dec 2003 19:31:55 -0500 Original-Received: from localhost (s4.uklinux.net [127.0.0.1]) by mail2.uklinux.net (Postfix) with ESMTP id 3D081409FB6; Mon, 29 Dec 2003 23:30:27 +0000 (UTC) Original-Received: from mail2.uklinux.net ([127.0.0.1]) by localhost (s4.uklinux.net [127.0.0.1:10024]) (amavisd-new) with ESMTP id 26754-02; Mon, 29 Dec 2003 23:29:54 +0000 (GMT) Original-Received: from laruns.ossau.uklinux.net (unknown [213.78.72.212]) by mail2.uklinux.net (Postfix) with ESMTP id 97D80409FA3; Mon, 29 Dec 2003 23:29:53 +0000 (UTC) Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 21CE0DC4D4; Mon, 29 Dec 2003 23:25:34 +0000 (GMT) Original-To: Marius Vollmer In-Reply-To: <87ptea40wu.fsf@zagadka.ping.de> Original-Lines: 77 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-Virus-Scanned: by amavisd-new X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3145 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3145 >>>>> "Marius" == Marius Vollmer writes: Marius> Neil Jerram 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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel