Re: problems building trunk in OpenBSD/i386

["Jan Djärv" <jan.h.d@swipnet.se>]

Ken Raeburn skrev:
> 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 meant the fact that pthread_once tries to initialize stuff twice.  After 
all, it should only do things once.  But I admit that this recursive calling 
of pthread_once is not very well specified as how it should behave.

> 
>> 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.

Maybe all this hooks and stuff can be removed if we switch to SYNC_INPUT.  I 
haven't checked all the details.

	Jan D.