[bug #18217] glibc: `__libc_once'
Update of bug #18217 (project hurd): Status:Upstream = Fixed Assigned to:None = roland Open/Closed:Open = Closed ___ Reply to this item at: http://savannah.gnu.org/bugs/?18217 ___ Message sent via/by Savannah http://savannah.gnu.org/
[bug #18217] glibc: `__libc_once'
Update of bug #18217 (project hurd): Status:None = Upstream ___ Follow-up Comment #3: A proposed patch is filed in upstream's Bugzilla: http://sourceware.org/bugzilla/show_bug.cgi?id=3748. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18217 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
Roland McGrath wrote: does not make sense Damn, I figured it didn't. Do we really need locking here or can we do without until we can implement nptl? Thanks! Barry ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18217] glibc: `__libc_once'
Follow-up Comment #2, bug #18217 (project hurd): Roland: ``Uli abused the macros. To support the use he wants, __libc_once should be revamped in all its implementations to return a value or have a variant that does (value says whether fn just ran).'' ___ Reply to this item at: http://savannah.gnu.org/bugs/?18217 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
Thomas Schwinge wrote:
Follow-up Comment #2, bug #18217 (project hurd):
Roland: ``Uli abused the macros. To support the use he wants, __libc_once
should be revamped in all its implementations to return a value or have a
variant that does (value says whether fn just ran).''
Is there any reason this wouldn't work?
Current code:
/* Use mutexes as once control variables. */
struct __libc_once
{
__libc_lock_t lock;
int done;
};
#define __libc_once_define(CLASS,NAME) \
CLASS struct __libc_once NAME = { MUTEX_INITIALIZER, 0 }
/* Call handler iff the first call. */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
do
{\
__libc_lock_lock
(ONCE_CONTROL.lock); \
if
(!ONCE_CONTROL.done) \
(INIT_FUNCTION)
(); \
ONCE_CONTROL.done =
1;\
__libc_lock_unlock
(ONCE_CONTROL.lock); \
} while (0)
Change to:
*Remove struct
#define __libc_once_define(CLASS,NAME) \
CLASS int NAME = MUTEX_INITIALIZER
/* Call handler iff the first call. */
#define __libc_once(ONCE_CONTROL, INIT_FUNCTION) \
do {
__libc_lock_lock(ONCE_CONTROL);
if ((ONCE_CONTROL) == MUTEX_INITIALIZER)
(INIT_FUNCTION)();
ONCE_CONTROL = 1;
__libc_lock_unlock(ONCE_CONTROL);
} while (0)
Or am I waaay off as usual?
Thanks!
Barry deFreese (aka bddebian)
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
does not make sense ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #18217] glibc: `__libc_once'
Uli abused the macros. To support the use he wants, __libc_once should be revamped in all its implementations to return a value or have a variant that does (value says whether fn just ran). ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
[bug #18217] glibc: `__libc_once'
Follow-up Comment #1, bug #18217 (project hurd): Is the applied usage of `old_once' in line 2029 supported? For the Mach / Hurd `__libc_once' functionality, we'd need to change that `if (old_once ...' to `if (old_once.done ...', I think. Do we need a common interface for that then, i.e. something like a macro `__libc_once_done(NAME)' which is defined to `NAME.done' for Mach / Hurd and plainly `NAME' for NPTL and then use that in line 2029? ___ Reply to this item at: http://savannah.gnu.org/bugs/?18217 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
