noren@dinl.uucp (Charles Noren) (08/18/90)
...its a Friday afternoon, and this new hacker to C++ wonders
what ignorant question can he ask the Net now...
How reentrant is C++ code? Suppose you have a class
(lets call it the infamous class foo), and you perform
a new on it, and suddenly a signal throws you into
your signal handler which also also does a new on foo which
calls your same constructor (or maybe the instance of foo is
not allocated from the heap, but on the stack as an automatic
class variable). What dangers are you faced with?
Now I'm sure that the makers of AT&T's Cfront and FSF's g++
have thought this out a long time ago, and that the mechanisms
to create, destroy, and do other wonderful things are all
reentrant. Has anyone ever run into these kind of problems?
Probably the real danger of C++ and signals is the ignorance
that new C++ coders (like myself) of what C++ really does with
things and inadvertantly writing non-reentrant code. To help
dispell this ignorance, I'll start a top 10 (20? 30?) list of
coding techniques that makes your code NON-reentrant:
1. Put read/write static variables inside your C++ functions
(especially handy when called from signal handlers).
2. Have nice structures (alright, objects) such as linked
lists that are used by both "normal" code and signal
handlers that both muck with the pointers (or call
member functions that muck with pointers) and not disable
signals in the critical code regions (or provide other
locking mechanisms).
...I'm just beginning the list, its Friday afternoon and I'm
out of here for the weekend...
--
Chuck Noren
NET: dinl!noren@ncar.ucar.edu
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930rfg@NCD.COM (Ron Guilmette) (08/18/90)
In article <1699@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: > >How reentrant is C++ code? ... ... >Probably the real danger of C++ and signals is the ignorance >that new C++ coders (like myself) of what C++ really does with >things and inadvertantly writing non-reentrant code. To help >dispell this ignorance, I'll start a top 10 (20? 30?) list of >coding techniques that makes your code NON-reentrant: > >1. Put read/write static variables inside your C++ functions > (especially handy when called from signal handlers). Just to clarify a bit, I believe that this could be restated as: Performing any operation on a variable (whose lifetime is the same as that of the entire program) which modifies that variable will tend to make your code non-reentrant. You mentioned one category of "permanent lifetime" variables (i.e. local variables declared as storage class `static') but there is also the category of all file-scope (global) variables to consider. This general rule applies to other languages as well (e.g. `C'). -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (08/20/90)
In article <1699@dinl.mmc.UUCP> noren@dinl.UUCP (Charles Noren) writes: > ... >How reentrant is C++ code? [...] At least up to Release 2.0, there was no mention whatsoever in the language specifications that a C++ compiler and run-time system should be required to provide for reentrancy at all! (Any changes in Release 2.1?). C++ is a sequential language, pure and simple. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
chip@tct.uucp (Chip Salzenberg) (08/21/90)
According to noren@dinl.UUCP (Charles Noren): >How reentrant is C++ code? Suppose you have a class >(lets call it the infamous class foo), and you perform >a new on it, and suddenly a signal throws you into >your signal handler which also also does a new on foo [...] Bzzt! You lose the portability sweepstakes. About the only portable thing you can do in a signal handler is set a flag of type sig_atomic_t (as defined in <sys/types.h>), or a plain int if you don't have a definition for sig_atomic_t. In general, doing memory management in a signal handler is a Very Bad Idea. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
landauer@morocco.Sun.COM (Doug Landauer) (08/22/90)
> C++ is a sequential language, pure and simple.
Well, most would agree that C++ is a sequential language, but I bet
that very few would agree that C++ is either pure or simple. :-) :-(