From owner-freebsd-chat Fri Jun 22 14:36:40 2001 Delivered-To: freebsd-chat@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B5C3E37B401 for ; Fri, 22 Jun 2001 14:36:37 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA03215; Fri, 22 Jun 2001 17:35:50 -0400 (EDT) Date: Fri, 22 Jun 2001 17:35:50 -0400 (EDT) From: Daniel Eischen To: Terry Lambert Cc: Dag-Erling Smorgrav , j mckitrick , freebsd-chat@FreeBSD.ORG Subject: Re: most complex code in BSD? In-Reply-To: <200106222119.OAA28520@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 22 Jun 2001, Terry Lambert wrote: > > The linker set code is odd. > > > > The build process for device modules is pretty opaque, especially > > when moving drivers between 4.x and 5.x. > > > > Anything with "perl" code in it: it's a write-only programming > > language, useful only for throw-away code. > > Forgot: > > The signal trampoline is pretty weird. > > The threads library signal masking to get around the non-restart > of signals that was brought into BSD with POSIX (the default used > to be signal restart) causes problems. There's a guy who is > having trouble with a siglongjmp() out of a signal handler when > using threads, right now. I guess he doesn't understand that the > thread that gets the signal and does the siglongjmp() is not > necessarily the thread that did the original setjmp()... Actually, I think this is FreeBSDs problem. I'm gonna look at it when I get some time (after USENIX hopefully). Under the threaded library in -stable, siglongjmp uses _thread_sys_sigprocmask() to restore the signal mask. This doesn't affect the _threads_ signal mask, though. Before the thread runs the signal handler, we add the current signal to the threads signal mask (like you're suppose to do). But when it siglongjmps out of the handler, the thread still has the signal masked. The next time the signal occurs, the threads library can't find a thread with the signal unmasked so it stores it as pending for the process and resumes processing the runnable threads. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message