Re: atexit
On Jul 26, 8:03 pm, Pete Becker <p...@versatilecoding.com> wrote:
James Kanze wrote:
On Jul 26, 5:37 pm, Pete Becker <p...@versatilecoding.com> wrote:
James Kanze wrote:
On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> wrote:
I've been looking at N2914. 3.6.3/3 only refers to non-local
statics.
There is no such thing as N2914. (The latest I can see is
N2881.)
N2914 is the working draft in the pre-Frankfurt mailing. It's
dated 2009-06-22. It's now the current working draft.
So I see. And I didn't have the latest mailings downloaded to
my machine here.
The wording of =A73.6.3 has been completely changed with regards
to the standard, to take into account threading and thread local
storage. And =A73.6.3 has been changed to exclude static objects
with local scope. Is this intentional, and for what reason?
(It may break existing programs.) Or is it an unintentional
side effect of some other change? I presume that the intent
here is to exclude objects with thread storage duration; if so,
should I raise a defect report, or is the original intent clear
enough that you could handle it as an editorial change. (It
looks a bit big for an editorial change to me, but if the
proposal that was actually voted on was clear, perhaps that
would be acceptable.)
It's still under discussion. See N2880 and and N2917. The problem
centers around interactions between detached threads and destruction of
function-static objects.
Ah yes. Threads still actively running while we're shutting
down.
I know that my own take has always been that it's undefined
behavior, and that if you have no way to ensure that a thread
will not be active when shutting down, don't detach it; join
before starting shutdown. Supposing it actually matters---in a
lot of cases, the possible "undefined behaviors" are in fact
limited to things that might be acceptable to many programs
during shutdown. Or you don't provide any provisions for
shutdown at all---the only way to stop the program is to kill
it, in which case, no destructors are run. Neither are what
I'd call nice, but both are quick and easy to implement. When
something cleaner is required, it's usually possible, with some
effort, to ensure that all threads reach an "inactive" state
before starting actual shutdown. So while I'm normally a very
strong opponent of anything which may lead to undefined
behavior, I do wonder if the committee isn't spending too much
time trying to define cases that shouldn't occur in well written
code, and are easy enough to avoid if one knows what one is
doing. (And of course, if one doesn't know what one is doing,
then just about everything to do with threading is potentially
undefined behavior.) In other words: if it's a question of
getting the standard out next meeting, with this as undefined
behavior, or waiting a year or so in order to find a perfect
solution (which we won't find anyway), I'd vote for right now.
(Of course, as long as concepts were there, the people working
on anything else had all the time in the world to do the best
job possible:-).)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34