[355] in Pthreads mailing list archive
Re: Fix to init pthreads earlier in C++
daemon@ATHENA.MIT.EDU (Rob Browning)
Sun Jul 7 13:04:36 1996
To: Ken Raeburn <raeburn@raeburn.org>
Cc: pthreads@MIT.EDU
From: Rob Browning <osiris@cs.utexas.edu>
Date: 07 Jul 1996 10:33:15 -0500
In-Reply-To: Ken Raeburn's message of 07 Jul 1996 04:50:33 -0400
Ken Raeburn <raeburn@raeburn.org> writes:
> C does guarantee it for program startup. Mixing C and C++ isn't
> language-defined, it's implementation defined.
I was afraid of 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.
Right, you can't guarantee anything about what order people will link
things in. You wouldn't want to depend on that if you don't have to.
> 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.
I agree, but I was just following the general principle of making it
as portable as possible when possible, but I know what you mean.
> The pthreads library already replaces _exit, so it's got control over
> the cleanup process. It also knows when the last thread exits.
Oh, of course, I hadn't been thinking about that.
> No, I think you're right.
Great, I was afraid of that too :>
So, if we're sure C/C++ (in the cases we care about) will always zero
(not necessarily "initialize") pthread_initial before any of the C++
or C static initializers fire, then I think your modifications are
fine, and make things somewhat more efficient.
--
Rob
