Date: Sat, 14 Aug 2010 18:23:55 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: "Sean C. Farley" <scf@FreeBSD.org> Cc: "Julian H. Stacey" <jhs@berklix.com>, Gabor Kovesdan <gabor@FreeBSD.org>, current@FreeBSD.org Subject: Re: Official request: Please make GNU grep the default Message-ID: <E1OkIaR-00086E-Em@kabab.cs.huji.ac.il> In-Reply-To: <alpine.BSF.2.00.1008140802510.35204@thor.farley.org> References: <201008141040.o7EAeiuR093012@fire.js.berklix.net> <alpine.BSF.2.00.1008140802510.35204@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sat, 14 Aug 2010, Julian H. Stacey wrote: > > >> why would you want to lock a file for reading anyways? > > > > Does current bsdgrep read lock by default ? > > If so, it would be better off by default, enabled by an option. > > 8.0-RELEASE man grep (gnu) does not mention locking. > > bsdgrep in -current does lock via the call to fgetc(). That is why I > suggested using flockfile/getchar_unlocked+/funlockfile instead. Other > unlocked functions would also be useful, i.e., feof_unlocked(). > Avoiding fgetc() does not completely solve the speed issue, yet it > certainly helps. > > Just for reference: older bsdgrep used fgetln(). let me rephrase the question: why would you want to lock a file for reading anyways?? there is no real benefit that I can see in locking a file for searching a pattern. On a single file the overhead is irrelevant, but for 'grep -r?' cheers, danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1OkIaR-00086E-Em>