[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems building trunk in OpenBSD/i386

From: Jan Djärv
Subject: Re: problems building trunk in OpenBSD/i386
Date: Fri, 20 Jul 2007 08:43:17 +0200
User-agent: Thunderbird (Macintosh/20070604)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]