From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11493 invoked by alias); 16 Sep 2009 00:46:07 -0000 Received: (qmail 11485 invoked by uid 22791); 16 Sep 2009 00:46:06 -0000 X-SWARE-Spam-Status: No, hits=-10.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint1.lanl.gov (HELO proofpoint1.lanl.gov) (204.121.3.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 00:46:02 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint1.lanl.gov (8.14.3/8.14.3) with ESMTP id n8G0k0HC000782 for ; Tue, 15 Sep 2009 18:46:00 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id C534915C9E56 for ; Tue, 15 Sep 2009 18:46:00 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id C3AEC7D009D for ; Tue, 15 Sep 2009 18:46:00 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id B48A47D009C for ; Tue, 15 Sep 2009 18:46:00 -0600 (MDT) Subject: Re: GSL 2.0 roadmap (one man's view) From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: 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> Content-Type: text/plain Date: Wed, 16 Sep 2009 00:46:00 -0000 Message-Id: <1253062112.23092.966.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-09-15_11:2009-09-01,2009-09-15,2009-09-15 signatures=0 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/msg00046.txt.bz2 regarding error handling: On Mon, 2009-09-07 at 14:57 +0100, Brian Gough wrote: > > 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). A combination of these seems right. We also have the usual problem of error codes for functions with natural prototypes. We should finally sort that out and do something coherent across the library. The _e and natural versions of the specfunc functions are just one example of that. Any ideas are welcome. We should think about this now, since it affects the interfaces across the library. > - use thread local storage for a global error control variable (not > 100% portable). I would like to know how non-portable this is. I mean, I understand it is different for every platform, but if everybody has one then it only becomes an issue of configuring the variability. Roughly speaking, I would think that every thread implementation must have a notion of thread-local storage, so we're never required to provide something that doesn't exist... -- G. Jungman