From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack unwinding for C code Date: Sat, 27 Dec 2003 18:37:37 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87ptea40wu.fsf@zagadka.ping.de> References: <87y8sz5kio.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 1072546875 7007 80.91.224.253 (27 Dec 2003 17:41:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 27 Dec 2003 17:41:15 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Dec 27 18:41:10 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 1AaIR3-0004LQ-00 for ; Sat, 27 Dec 2003 18:41:09 +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 1AaJLn-0002MQ-O6 for guile-devel@m.gmane.org; Sat, 27 Dec 2003 13:39:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AaJLg-0002Ly-JT for guile-devel@gnu.org; Sat, 27 Dec 2003 13:39:40 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AaJLA-0002Gl-I1 for guile-devel@gnu.org; Sat, 27 Dec 2003 13:39:39 -0500 Original-Received: from [195.253.8.218] (helo=mail.dokom.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AaJLA-0002Gf-3s for guile-devel@gnu.org; Sat, 27 Dec 2003 13:39:08 -0500 Original-Received: from dialin.speedway43.dip96.dokom.de ([195.138.43.96] helo=zagadka.ping.de) by mail.dokom.net with smtp (Exim 3.36 #3) id 1AaIO6-0001aQ-00 for guile-devel@gnu.org; Sat, 27 Dec 2003 18:38:06 +0100 Original-Received: (qmail 20306 invoked by uid 1000); 27 Dec 2003 17:37:37 -0000 Original-To: Neil Jerram In-Reply-To: (Neil Jerram's message of "27 Dec 2003 12:11:26 +0000") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) 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:3139 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3139 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. Don't you think we need it? Maybe I'm overlooking some obvious alternative that would work just as well... The example shows what I want to achieve: during a sequence of conversions from SCM objects to C data structures, we will frequently have the case that an earlier conversion has allocated some resources that need to be freed later on. However a later conversion might want to throw an error and the cleanup needs to happen then. First, we (on #guile) tried some approaches that would prevent the throwing of errors. For example, we could separate type checking and conversion, ala scm_check_string (s1); scm_check_string (s2); /* Now the conversion functions are guaranteed not to throw. */ c_s1 = scm_to_string (s1); c_s2 = scm_to_string (s2); But this leads to problems in a multi-threaded program: when you have composite SCM types such as a list, you must make absolutely sure that the object doesn't change from checking to conversion. You need to stop all other guile threads during the conversion sequence, which is at least as costly as having this unwind machinery, I think. > A few comments and typo corrections, > though ... Thanks, hopefully the poor form didn't distract from the content... > Marius> These frames also inhibit continuations (as explained > Marius> below). [...] > > 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. Hmm. I had to change the continuation stuff already: just disallowing all construction and invocation of continuations is too restricitve: continuations that are only used below the frame cause no harm. Only continuations that cause the frame to be rewound need to be prevented. This is too restrictive as well, in a sense, since continuations that are only used in a suspend/resume way (for threads or coroutines, say) are OK as well. But the general continuations are too general to know how they are going to be used, so throwing an error when such a frame is rewound is all we can do. > Marius> scm_begin_frame ("foo"); > Marius> { > > Is this block necessary? - it looks a little ugly to me. No, scm_begin_frame is a normal function, nothing special about it. > Marius> Starts a new frame and makes it the 'current' one. > Marius> The frame will be 'non-continueable', see below. > > typo - "continuable" Yeah, thanks. :-) I knew it was wrong, but I couldn't figure out what was right. Ispell doesn't know about "continuable"... > Also differs - perhaps confusingly - from my use of "continuable" for > a stack in (ice-9 debugger). (My use of "continuable" is to describe > a stack at a breakpoint, where execution can continue, as opposed to > the-last-stack after an error, where execution cannot continue. Yes, the term isn't very good for what I use it for. > Perhaps "continuation-proof" or "continuation-protected"? What about "rewindable"? > Marius> The given LABEL will appear in backtraces and error messages. > > How (out of interest)? Don't know yet! :-) Also, I'm no longer sure that it is a good idea to combine the backtrace stuff with the frame stuff. I think I'll remove the label. (I think that ultimately, we should have a different way of reporting error from C code: we should not include the subr name in the call to the error reporting function but rather rely on a more general mechanism for providing a backtrace for C code. I found it attractive to just combine it with the frame stuff, but it probably is too early...) > > Marius> The frame is ended either implicitely when a non-local > Marius> exit happens, or explicitely with scm_end_frame. > > typos - "implicitly", "explicitly" Oops, I do that all the time... > Marius> Arranges for FUNC to be called with DATA as its > Marius> arguments when the current frame ends implicitely. > Marius> When EXPLICITElY is non-zero, FUNC is also called when > Marius> the frame ends explicitely. > > "If" sounds better than "When" here, I'd say. Ok. > 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 ? Hmm. That is so technical. I wanted to imply that scm_c_define_proc is the usual way to export C procedures to Scheme. Even if you don't explicitly ;) ask for a frame, you still get it since it is good for you.... But, yeah, I'm removing this together with the label stuff. > Marius> Also, the frames stored by the debugging evaluator could > Marius> be combined with this. > > Interesting. Do you propose to do this as part of your initial work? Well, no. They are too different after all. It is very nice how efficient the debugging frames currently are, and I wouldn't want to destroy that. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel