Re: confusing fork/readline behaviour

Can someone explain what is going on please?

Both processes share the same ~~filehandle~~ file descriptor, plus the libc usually reads ahead. If /etc/passwd is small enough, the libc slurps the entire file in one process during the first getline(), leaving nothing for the other process.

Quoting from the linux man page of fork(2):

The child inherits copies of the parent's set of open file descriptors. Each file descriptor in the child refers to the same open file description (see open(2)) as the corresponding file descriptor in the parent. This means that the two descriptors share open file status flags, current file offset, and signal-driven I/O attributes (see the description of F_SETOWN and F_SETSIG in fcntl(2)).

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Comment on Re: confusing fork/readline behaviour

Replies are listed 'Best First'.
Re^2: confusing fork/readline behaviour by flipper (Beadle) on Aug 13, 2015 at 18:52 UTC
Ah that makes sense, thanks. Presumably my script above is unsafe in the general case - I imagine libc could readahead 4k and not finish on a line boundary, then the second process would call readline and start halfway through a line...	[reply]
Re^3: confusing fork/readline behaviour by afoken (Chancellor) on Aug 14, 2015 at 18:22 UTC
Presumably my script above is unsafe in the general case - I imagine libc could readahead 4k and not finish on a line boundary, then the second process would call readline and start halfway through a line. Correct. Why do you want two processes to read the same file? Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]