Date: Sun, 17 Jul 2005 22:00:53 -0700 From: Pascal Hofstee <caelian@gmail.com> To: freebsd-threads@freebsd.org Cc: David Ayers <d.ayers@inode.at> Subject: [PATCH] Re: GNUstep, libobjc and threading Message-ID: <1121662853.701.10.camel@synergy.charterpipeline.net.lan> In-Reply-To: <1121453983.672.15.camel@synergy.charterpipeline.net.lan>
index | next in thread | previous in thread | raw e-mail
On Fri, 2005-07-15 at 12:00 -0700, Pascal Hofstee wrote:
> Is the above analysis enough information to hopefully fix this problem
> with FreeBSD's threading libraries ... and would properly gaurding the
> mentioned pthread_key_create function with a similar _thread_initial
> check be sufficient ?
Well .. i decided to give it a shot and tried to patch up libpthread
myself with the information provided by David Ayers. And i have so far
seen no ill-effects of my changes, but at least these GNUstep problems
now are resolved.
(GNUstep and FreeBSD/amd64 still don't exactly like eachother but that's
because of at least a number of potential 64-bit issues which we're
currently trying to resolve within GNUstep itself.)
Below patches fix the problem as described in the analysis:
--- lib/libpthread/thread/thr_spec.c.orig Sat Jul 16 19:28:31 2005
+++ lib/libpthread/thread/thr_spec.c Sat Jul 16 19:28:41 2005
@@ -50,8 +50,13 @@
int
_pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
{
- struct pthread *curthread = _get_curthread();
+ struct pthread *curthread;
int i;
+
+ if (_thr_initial == NULL)
+ _libpthread_init(NULL);
+
+ curthread = _get_curthread();
/* Lock the key table: */
THR_LOCK_ACQUIRE(curthread, &_keytable_lock);
--- lib/libthr/thread/thr_spec.c.orig Sat Jul 16 19:29:04 2005
+++ lib/libthr/thread/thr_spec.c Sat Jul 16 19:29:14 2005
@@ -52,8 +52,13 @@
int
_pthread_key_create(pthread_key_t *key, void (*destructor) (void *))
{
- struct pthread *curthread = _get_curthread();
+ struct pthread *curthread;
int i;
+
+ if (_thr_initial == NULL)
+ _libpthread_init(NULL);
+
+ curthread = _get_curthread();
/* Lock the key table: */
THR_LOCK_ACQUIRE(curthread, &_keytable_lock);
I just realized it may be possible to do the whole _thr_initial dance
inside the actual _get_curthread() function ... if that turns out to be
the case .. perhaps that location would be more suitable than this
'stopgap'.
With kind regards,
Pascal Hofstee
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1121662853.701.10.camel>