From: "Wolfram Gloger" <wg@malloc.de>
To: carlos@baldric.uwo.ca
Cc: parisc-linux@lists.parisc-linux.org
Subject: [parisc-linux] Re: [RFC] Where to put arch-dependant locking in malloc/thread-m.h
Date: 10 Oct 2003 12:22:06 -0000 [thread overview]
Message-ID: <20031010122206.714.qmail@w2.w-local> (raw)
In-Reply-To: "carlos@baldric.uwo.ca"'s message of Thu, 25 Sep 2003 17:15:09 -0400
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Hi,
>The following patch fixes the issue, but I'm not content about it's
>placement in malloc/thread-m.h. Any comments about where I might put
>this in order to make maintenance easier?
The malloc-machine.h specific headers are now in place,
so you might want to propose something like the following?
Regards,
Wolfram.
2003-10-10 Carlos O'Donell <carlos@baldric.uwo.ca>
* sysdeps/hppa/malloc-machine.h: New file.
[-- Attachment #2: malloc-machine.h --]
[-- Type: application/octet-stream, Size: 2774 bytes --]
/* Basic platform-independent macro definitions for mutexes,
thread-specific data and parameters for malloc.
Copyright (C) 2003 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
#ifndef _MALLOC_MACHINE_H
#define _MALLOC_MACHINE_H
#undef thread_atfork_static
#include <atomic.h>
#include <bits/libc-lock.h>
__libc_lock_define (typedef, mutex_t)
/* Since our lock structure does not tolerate being initialized to
zero, we must modify the standard function calls made by malloc */
#define mutex_init(m) \
__libc_maybe_call (__pthread_mutex_init, (m, NULL), \
(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT),(*(int *)(m))) )
#define mutex_lock(m) \
__libc_maybe_call (__pthread_mutex_lock, (m), \
(__load_and_clear(&((m)->__m_lock.__spinlock)), 0))
#define mutex_trylock(m) \
__libc_maybe_call (__pthread_mutex_trylock, (m), \
(*(int *)(m) ? 1 : (__load_and_clear(&((m)->__m_lock.__spinlock)), 0)))
#define mutex_unlock(m) \
__libc_maybe_call (__pthread_mutex_unlock, (m), \
(((m)->__m_lock.__spinlock = __LT_SPINLOCK_INIT), (*(int *)(m))) )
/* This is defined by newer gcc version unique for each module. */
extern void *__dso_handle __attribute__ ((__weak__));
#include <fork.h>
#ifdef SHARED
# define thread_atfork(prepare, parent, child) \
__register_atfork (prepare, parent, child, __dso_handle)
#else
# define thread_atfork(prepare, parent, child) \
__register_atfork (prepare, parent, child, \
&__dso_handle == NULL ? NULL : __dso_handle)
#endif
/* thread specific data for glibc */
#include <bits/libc-tsd.h>
typedef int tsd_key_t[1]; /* no key data structure, libc magic does it */
__libc_tsd_define (static, MALLOC) /* declaration/common definition */
#define tsd_key_create(key, destr) ((void) (key))
#define tsd_setspecific(key, data) __libc_tsd_set (MALLOC, (data))
#define tsd_getspecific(key, vptr) ((vptr) = __libc_tsd_get (MALLOC))
#include <sysdeps/generic/malloc-machine.h>
#endif /* !defined(_MALLOC_MACHINE_H) */
next reply other threads:[~2003-10-10 12:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-10 12:22 Wolfram Gloger [this message]
2003-10-10 20:28 ` [parisc-linux] Re: [RFC] Where to put arch-dependant locking in malloc/thread-m.h Carlos O'Donell
-- strict thread matches above, loose matches on Subject: below --
2003-09-25 21:15 [parisc-linux] " Carlos O'Donell
2003-09-26 13:39 ` [parisc-linux] " wmglo
2003-09-26 14:24 ` Carlos O'Donell
2003-09-26 14:24 ` Carlos O'Donell
2003-09-26 13:39 ` wmglo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031010122206.714.qmail@w2.w-local \
--to=wg@malloc.de \
--cc=carlos@baldric.uwo.ca \
--cc=parisc-linux@lists.parisc-linux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox