Date: Tue, 29 Apr 2003 09:41:15 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <XFMail.20030429094115.jdp@polstra.com> In-Reply-To: <Pine.GSO.4.10.10304282211190.28966-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Daniel, > So I was glancing at rltd-elf, specifically lockdflt.c. There > seems to be an assumption that sigprocmask() can be used to > protect a thread from being swapped out. Am I reading this > right? > > There are no such guarantees with libpthread. A thread > will be swapped out whenever its quantum expires, and if > you've got higher priority threads, they will always run > before those of lower priority -- even if they are spinning. > > I'm trying to debug weird hangs with mozilla. Once it > hangs, I can't kill it except with SIGKILL, and then > it seems to be stuck in symlook_obj(). I'd strongly recommend that you read the complete log messages for "src/libexec/rtld-elf/i386/lockdflt.c" in chronological order to find out what all has been tried and why none of it worked. It's a pretty sad history. :-( I now believe that the most workable solution is to rejigger the data structures inside the dynamic linker such that locking is no longer needed for normal operations (loading shared libraries, resolving symbol references, performing lazy binding, etc.). I think it's possible to change things so that the only time locking is needed is to prevent multiple invocations of dlopen, dlclose, etc., from interfering with each other. Trying to tie into the pthread locking functions didn't work, because (1) it is too hard to prevent lazy binding from occuring as a result of calling the locking functions themselves, and (2) there are lots of applications out there that use their own threads packages instead of the system's. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030429094115.jdp>