[354] in Pthreads mailing list archive
Re: Fix to init pthreads earlier in C++
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sun Jul 7 05:11:48 1996
To: Rob Browning <osiris@cs.utexas.edu>
Cc: pthreads@MIT.EDU
From: Ken Raeburn <raeburn@raeburn.org>
Date: 07 Jul 1996 04:50:33 -0400
In-Reply-To: Rob Browning's message of 07 Jul 1996 02:38:21 -0500
Rob Browning <osiris@cs.utexas.edu> writes:
> I'm not up on the details of statics from C files when mixed with
> statics from C++ files. Are you sure that pthread_initial (since
> global.c is compiled as a C, not C++ file) is guaranteed to be zeroed
> *before* *any* of g++'s static initializers fire? If not, then this
> is dangerous.
C does guarantee it for program startup. Mixing C and C++ isn't
language-defined, it's implementation defined. But I don't know of an
implementation that would do it in a way that wouldn't work for us.
I've sent a query off to some of the folks at Cygnus who maintain the
G++ compiler. I *thought* all existing C++ implementations (well, all
reasonable ones anyways :-) would initialize statics from libraries
first, reversed from link order. So if you include a library that
calls pthread_* routines and has static initializers, listing it on
the linker command line after the pthreads library wouldn't work --
but then, the way many linkers work, the program probably wouldn't
link that way anyways.
Besides, pthread_init checks pthread_initial. :-)
> Your approach is probably OK, but unless ANSI guarantees the
> semantics, it might not be as portable.
True, but remember we're dealing with real systems here. ANSI doesn't
say anything about file descriptors, or being able to replace stdio
functions, either. If it works across the systems we're dealing with,
that's adequate.
> Also bear in mind that it's
> definitely not going to work if pthreads ever wants to have some
> library cleanup in the future that gets executed whenever all program
> code is finished using pthreads. In such a case, you'll have to have
> the counter and the semaphore, but you probably knew that...
The pthreads library already replaces _exit, so it's got control over
the cleanup process. It also knows when the last thread exits.
> >From Stroustroup and Ellis (p 19): "The initialization of nonlocal
> static objects in a translation unit is done before the first use of
> any function or object defined in that translation unit."
>
> So say some static object's constructor calls functions in the same
> translation unit. In such a situation it's impossible to guarantee
> that all the static initializers will be called before any of the
> functions since the static initializers themselves call the functions?
> I'm probably just being too pedantic...
No, I think you're right.
