Re: problems building trunk in OpenBSD/i386

[Ken Raeburn <raeburn@raeburn.org>]

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.