From owner-p4-projects@FreeBSD.ORG Tue Jul 31 20:00:17 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 4522116A49E; Tue, 31 Jul 2007 20:00:17 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A00816A496 for ; Tue, 31 Jul 2007 20:00:17 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from decibel.pvv.ntnu.no (unknown [IPv6:2001:700:300:1900:2e0:81ff:fe2d:e9b2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFD213C480 for ; Tue, 31 Jul 2007 20:00:16 +0000 (UTC) (envelope-from lulf@FreeBSD.org) Received: from tvilling.pvv.ntnu.no ([129.241.210.198] helo=carrot.studby.ntnu.no ident=lulf) by decibel.pvv.ntnu.no with esmtp (Exim 4.60) (envelope-from ) id 1IFxt2-0002qe-Ep for perforce@FreeBSD.org; Tue, 31 Jul 2007 22:00:11 +0200 Date: Tue, 31 Jul 2007 21:59:37 +0200 From: Ulf Lilleengen Message-ID: <20070731195937.GA1379@carrot.studby.ntnu.no> References: <200707301047.l6UAlD8L092463@repoman.freebsd.org> <20070731175105.GU1092@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070731175105.GU1092@garage.freebsd.pl> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Perforce Change Reviews Subject: Re: PERFORCE change 124344 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2007 20:00:17 -0000 On Tue, Jul 31, 2007 at 07:51:05PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Jul 30, 2007 at 10:47:13AM +0000, Ulf Lilleengen wrote: > > http://perforce.freebsd.org/chv.cgi?CH=124344 > > > > Change 124344 by lulf@lulf_carrot on 2007/07/30 10:47:07 > > > > - Sleep after sending create requests in userland, since the event might > > not yet be processed. If there are noteable issues with this, which is > > a quite unlikely to happen, I have a patch to support suspending > > of the userland process until the events are executed, but it's only > > required in this special case. > > Sleeping that way is, as you noted, not very nice... Can't you put a > loop below errstr check, which will wait for drive creation. You could > sleep for eg. 0.1s between checks. Also not very nice, but even 2s may > be too low on very loaded systems. Hmm, yes I agree. Just committed a fix that does this. I'm more and more considering the suspending patch :) Anyway.. thanks. -- Ulf Lilleengen