[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems building trunk in OpenBSD/i386
From: |
Ken Raeburn |
Subject: |
Re: problems building trunk in OpenBSD/i386 |
Date: |
Thu, 19 Jul 2007 21:18:32 -0400 |
On Jul 13, 2007, at 3:23, Jan Djärv wrote:
Ken Raeburn skrev:
The other parts of the stack trace indicate that the rest of the
loop is in the C library -- pthread_once calls pthread_mutex_lock,
which initializes some thread support code, which is causing some
priority queue code to try to allocate storage, which winds up
calling into gmalloc, which again ensures that initialization has
been done by calling pthread_once.
This sounds like a bug in pthread_once.
Which part? I think having it allocate storage is perfectly
acceptable, though if you're explicitly linking against the thread
library it'd probably be quicker for stuff that'll always be needed
to be allocated in static storage. One might argue that internal
uses of standard C library functions by the system library functions
should use specially named internal versions of the C library
functions so as to prevent overriding them, but then you get into
questions of where you draw the line(s), and what "overriding" is
really supposed to do.
I think we safely can call malloc_initialize from main itself
without thread protection. The protection is from threads created
by the file dialog, and they get created when the dialog is first
used. So we should be safe.
That sounds like it'll probably work, yes... guess I was looking for
a too-general solution, suitable for other uses of this gmalloc.c.
The semantics of some pthread operations and their interactions with
the language specs are sufficiently vague and subtle[1] that I'd be
wary of removing any pthread operations, but since malloc_initialize
and then malloc (with its mutex locking) would be called in the main
thread before any other threads are created, I think it's probably safe.
Ken
[1] See http://portal.acm.org/citation.cfm?id=1065042 for some examples.