On 3/30/07, Rajat Jain <rajat.noida.india@xxxxxxxxx> wrote:
> >
> > This has reference to LDD3 chap3 - Char drivers (Pg 60).
> >
> > The following is my understanding which seems to be incorrect. Can
> > somebody please point out what am I missing?
> >
> > LDD3 states that the fops->open() and fops->release() methods are
> > called only when "struct file" is created / destroyed. It further says
> > that "struct file" is created ONLY when a process calls open() system
> > all on a file. To give an example, it also says that if process 1
> > opens file A and then forks another process B, then A and B will share
> > the same struct file??
>
> LDD3 is correct. Processes A and B will share the same struct file
> in case of fork.
>
> >
> > This seems quite strange to me as I had an understanding that two
> > processes working on the same file will always have different file
> > structure. Also, this would mean that a read by one of the processes
> > on the file would affect the file position pointer in the other
> > process?
>
> It is not strange. It depends on how the two processes work on the same
> file. If each one opens the file, then two struct file structures are
created
> in the kernel. This way, a read by one of the processes does not affect
> the file position pointer in the other process. But it does affect in case
> of fork.
>
> > I am sure I am missing something here. What is it?
>
> Here is a small example to demonstrate the fork situation.
> This small program reads data either from stdin or an input file.
> In case of a file, it first opens the file for reading. It then forks.
> Then both the parent and the child are reading. When you try it out,
> you'll see that both affect each others read position.
>
Whooaa!! That is a shocking discovery. I had an understanding that 2
processes will never share any resource except when EXPLICITLY told
to. Thanks for clarifying my doubts.
However, I am wondering how is it going to work out in a scenario
where file locking (flock?) is implemented?
from man fork
* The child does not inherit record locks from its parent (fcntl(2)).
just a confirmation
* 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 sig-
nal-driven I/O attributes (see the description of F_SETOWN
and F_SETSIG in
fcntl(2)).
i think read some where that this behavior is there to facilitate
communication between parent & child without much hassles
most probably in Richard Stevens Advanced programming in Unix environment
got to chk it out
--
Milind Arun Choudhary
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
