Date: Fri, 10 Mar 2000 13:57:20 -0800 (PST) From: John Polstra <jdp@polstra.com> To: bloom@acm.org Cc: current@freebsd.org Subject: Re: More "ld-elf.so.1: assert failed" messages Message-ID: <200003102157.NAA43351@vashon.polstra.com> In-Reply-To: <38C8610C.E17A41EF@acm.org> References: <13611.952595759@zippy.cdrom.com> <200003100054.BAA64158@saturn.kn-bremen.de> <38C8610C.E17A41EF@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <38C8610C.E17A41EF@acm.org>, Jim Bloom <bloom@acm.org> wrote: [when dllockinit() should be called] > It should be called somewhere between the starting of the process > and the creation of the second thread. There is no problem if there > is only one thread. > > THREAD Create would be fine as long as it sets a variable accessible > to all threads indicating dllockinit has been called. > > Another possible location would be a routine that initialize the > multithreading for the process. This routine may not exist in all > thread packages though. That is all correct. Dllockinit has to be called once only, before any threads have been forked but late enough so that it's safe to call the thread sychronization primitives. Ideally, a reader/writer lock should be used. But it will also work to use a simple mutex. In that case, rlock_acquire and wlock_aquire will be the same (lock the mutex). I'd recommend using a simple mutex unless the threads package already implements reader/writer locks. I really hope I can render all this nonsense unnecessary after the code freeze ends. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003102157.NAA43351>