🚀 go-pugleaf

In article <DLCosx.Hn1@falcon.daytonoh.attgis.com> Dick Menninger
<Dick.Menninger@daytonoh.attgis.com> writes:

> > ==========Steve Clamage, 1/16/96==========
> > In C, a signal handler isn't allowed to do much of anything, precisely
> > because the program state can't be known and may be inconsistent. The
> > same is true in C++.

> It is just like an interrupt handler in that it could
> deadlock with the code it preempts.  OSes deal with
> that and do quite meaty stuff in the interrupt handlers.
> I certainly hope you are NOT trying to preclude the
> use of exceptions in interrupt handlers.  That would
> be totally absurd.

From ISO 9899, section 7.7.1.1: ``If the signal occurs other than as the
result of calling the abort or raise function, the behavior is undefined
if the signal handler calls any function in the standard library other
than the signal function itself (with a first argument of the signal
number corresponding to the signal tha caused the invocation of the
handler) or refers to any object with static storage duration other than
by assigning a value to a static storage duration variable of type
volatile sig_atomic_t.''

In light of this, about all that one might be able to require with
regards to exceptions is that 1) you can throw a sig_atomic_t request,
2) the signal must be caught in the signal handler, and 3) you cannot
read the value of the exception.

Quite frankly, this seems like an awful lot of complication for a very
little gain.

Implementations which can are free to guarantee more.

> > Allowing exceptions to be thrown from a signal handler would place a
> > noticeable penalty on all programs to provide locks on every function
> > entry and exit, even programs that didn't throw exceptions or use
> > signals.

> I don't think so.  That does not follow at all.
> See the earlier comments.
   [Which I deleted in the followup...]

I agree fully in your comparison of signal handlers to separate threads.
The standard does not make any guarantees with regards to separate
threads, however, so this comparison does *not* help in defining what a
signal handler could do.  Many implementations do not have any notion of
threads.

As a quality of implementation issue, perhaps it wouldn't be too much to
ask that in implementations that support threading, the signal handler
will allow anything that would normally be thread safe.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
              -- A la recherche d'une activité dans une region francophone

From daemon@ncar.UCAR.EDU Fri Jan 19 13:04 PST 1996
Return-Path: <daemon@ncar.UCAR.EDU>
Received: from Eng.Sun.COM by pacific.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA14727; Fri, 19 Jan 1996 13:04:38 -0800
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15650; Fri, 19 Jan 1996 13:03:15 -0800
Received: from ncar.UCAR.EDU by mercury.Sun.COM (Sun.COM)
	id NAA04416; Fri, 19 Jan 1996 13:03:05 -0800
Received: by ncar.ucar.EDU (NCAR Local/ NCAR Central Post Office 03/11/93)
	id OAA04514; Fri, 19 Jan 1996 14:02:56 -0700 (MST)
Received: from relay6.UU.NET by ncar.ucar.EDU (NCAR Local/ NCAR Central Post Office 03/11/93)
	id OAA04501; Fri, 19 Jan 1996 14:02:49 -0700 (MST)
Received: from mail1.its.rpi.edu by relay6.UU.NET with SMTP 
	id QQzzfw27411; Fri, 19 Jan 1996 16:02:46 -0500 (EST)
Received: from usenet.rpi.edu (usenet.rpi.edu [128.113.100.14]) by mail1.its.rpi.edu (8.6.9/8.6.4) with SMTP id QAA13826; Fri, 19 Jan 1996 16:02:41 -0500
Received: by usenet.rpi.edu (4.1/ST26-USENET);
	id AA13786; Fri, 19 Jan 96 16:07:26 EST for wiseb@cs.rpi.edu
To: comp-std-c++@uunet.uu.net
From: Bowden Wise <wiseb@cs.rpi.edu>
Newsgroups: comp.std.c++
Subject: Re: auto_ptr again
Organization: Rensselaer Polytechnic Institute, Computer Science
Lines: 16
Message-Id: <31003068.C10@cs.rpi.edu>
References: <ADxYD_mKQD@qsar.chem.msu.su> <4djrn4$js1@engnews1.Eng.Sun.COM>
		<AUSTERN.96Jan18103535@isolde.mti.sgi.com> <KANZE.96Jan19124039@gabi.gabi-soft.fr>
X-Nntp-Posting-Host: hoover.cs.rpi.edu
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0b3 (Win16; I)
Cc: wiseb@cs.rpi.edu
X-Lines: 16
Content-Type: text/plain; charset="us-ascii"
Content-Length: 582
Approved: clamage@eng.sun.com (comp.std.c++)

J. Kanze wrote:

> I use reference counted pointers a lot, but they have their own set of
> problems.  I can very well understand the committees reluctance to 
> adapt them.

Can you share with us the problems with reference counter pointers?
How do those problems compare with the auto_ptr problems?  Perhaps
we need some kind of hybrid between the two.

Bowden

--------------------------------------------------------------------
G. Bowden Wise
Computer Science Dept, Rensselaer Polytechnic Inst, Troy, NY 12180
Email: wiseb@cs.rpi.edu         WWW: http://www.cs.rpi.edu/~wiseb/

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]