On Sat, Aug 14, 2010 at 06:23:55PM +0300, Daniel Braniss wrote: > > 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?' Locked is not a file, but FILE. It is a measure to establish consistency in the stdio structures in the multithreaded environment, and not a file-system level lock of any kind. See the description of the flockfile() in the SUSv4. On the other hand, the overhead of locking in !mt process for FILE in our libc should be unmeasurable.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:06 UTC