From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 15:58:58 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C847D106567B for ; Fri, 18 Jul 2008 15:58:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (meestal-mk5.stack.nl [IPv6:2001:610:1108:5010::149]) by mx1.freebsd.org (Postfix) with ESMTP id 80FFA8FC14 for ; Fri, 18 Jul 2008 15:58:58 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 190043F89B; Fri, 18 Jul 2008 17:58:57 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 0A5B2228C5; Fri, 18 Jul 2008 17:58:57 +0200 (CEST) Date: Fri, 18 Jul 2008 17:58:56 +0200 From: Jilles Tjoelker To: Michael B Allen Message-ID: <20080718155856.GA96280@stack.nl> References: <78c6bd860807121611w4f6ab44brbebfffea9929682a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78c6bd860807121611w4f6ab44brbebfffea9929682a@mail.gmail.com> X-Operating-System: FreeBSD 7.0-STABLE i386 User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers Subject: Re: Pls sanity check my semtimedop(2) implementation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2008 15:58:58 -0000 On Sat, Jul 12, 2008 at 07:11:26PM -0400, Michael B Allen wrote: > Below is a semtimedop(2) implementation that I'm using for FreeBSD. I > was hoping someone could look it over and tell me if they think the > implementation is sound. > [snip semtimedop implementation that uses SIGALRM and relies on EINTR] > The code seems to work ok but when stressing the FreeBSD build of my app > I have managed to provoke errors related to concurrency (usually when a > SIGALRM goes off). The Linux build works flawlessesly so I'm wondering > about this one critical function that is different. In your implementation, the SIGALRM signal may happen before you even call semop(2). If so, most likely the semop(2) will hang arbitrarily long. A somewhat dirty fix is to put a nonzero value into it_interval. This will ensure that if a signal is missed another one will be generated quickly. You might be able to fix this using setjmp/longjmp, but this is neither pretty nor efficient. Another dirty fix is to try non-blocking semop(2) several times with sleeps in between. > Do you think it would make any difference if I used > ITIMER_VIRTUAL / SIGVTALRM instead of ITIMER_REAL / SIGALRM? This does not fix the inherent problem. Also, given your use of signals in the first place, your application must be single threaded. This means the ITIMER_VIRTUAL timer does not run while semop(2) is waiting. -- Jilles Tjoelker