From owner-freebsd-hackers Sat Feb 27 12:28:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 45B2D15151 for ; Sat, 27 Feb 1999 12:27:40 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA11820; Sat, 27 Feb 1999 13:27:24 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd011806; Sat Feb 27 13:27:14 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA13546; Sat, 27 Feb 1999 13:27:13 -0700 (MST) From: Terry Lambert Message-Id: <199902272027.NAA13546@usr09.primenet.com> Subject: Re: flock and kernel threads To: jplevyak@inktomi.com (John Plevyak) Date: Sat, 27 Feb 1999 20:27:13 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990223214744.A24606@proxydev.inktomi.com> from "John Plevyak" at Feb 23, 99 09:47:44 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I believe there may be a problem with lockfiles (flock) and > kernel threads. The problem is demonstrated by the enclosed > program, which if run twice will fail the second time. > > The problem seems to be that termination via signal of > the non-main thread (non-leader) does not (always) result > in a call to closef and hence a call to lf_clearlock. > > Suggestions, comments welcome. This happens because fd's are scoped to the process (it's an index intpo the per process open file table) and not to the thread that opened them. Consider that if they were scoped to the thread that did the open, you would not be able to do useful things like handing incoming socket connections off to worker threads. To resolve this, you either need to register a cleanup mechanism that knows about per thread state: man pthread_cleanup_push This is less than ideal, since it means that your threading architecture in your program is not very SMP scalable, by its design. In general, thread use should be limited as much as possible to a "work to do model", with any persistent state that will survive across transactions scoped globally in a per "session" state structure. Refeerences to the literature available on request (or you can scan the -current and -hackers list archives). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message