From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22544 invoked by alias); 7 Sep 2009 15:10:33 -0000 Received: (qmail 22495 invoked by uid 22791); 7 Sep 2009 15:10:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.network-theory.co.uk (HELO mail.network-theory.co.uk) (66.199.228.187) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 15:10:17 +0000 Date: Mon, 07 Sep 2009 15:10:00 -0000 Message-ID: From: Brian Gough To: GSL Discuss Mailing List Subject: Re: GSL 2.0 roadmap (one man's view) In-Reply-To: <1251414939.23092.82.camel@manticore.lanl.gov> References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Message-Mac: 3b0b5708cd4825eacaadd779d05e233d Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00033.txt.bz2 At Thu, 27 Aug 2009 17:15:39 -0600, Gerard Jungman wrote: > GSL implements a very rudimentary type of error-handling, which > is quite appropriate for small projects. The "register handler, > fail-by-default" model works for a small library with a "low > stack depth" usage model. By this, I mean that library functions > are called by clients, but not by other library functions; in > such a case, it is easy for the client to interpret the errors. > But GSL does not conform to this "low stack depth" usage model, > and the fail-by-default model can be confusing for clients, when > the failure occurs at depths that they cannot control. The issue here is threading -- otherwise we could use a global variable to control the behaviour. Either we have to - pass an extra argument to all(?) functions for error control (seems a large impact for a relatively small problem) - provide separate _impl non-aborting versions for functions called internally, similar to the special functions (simplest option). - use thread local storage for a global error control variable (not 100% portable). -- Brian Gough