In particular, if only the child is going to be using the locked file handle, why would you need or want to open/lock the file before forking? You could just do this in the child process after the fork, and not worry about what happens across a fork. The same reasoning would apply if only the parent were doing stuff with the file in question. OTOH, if the plan is for the parent to do something with the locked file either before or after the child works on it, why even do the fork in the first place (unless there is enough other stuff to do, not involving the file, that makes the fork worthwhile)?
Now, if your idea is that both child and parent are going to be doing things "in parallel" with this one locked file, you're likely to run into problems whose symptoms might be really strange, unpredictable and hard to debug. One of the main reasons for file locking in the first place is to keep concurrent processes from trampling each other when working with the same external resource.
In reply to Re: Fork + Flock = Who Gets the Lock?
by graff
in thread Fork + Flock = Who Gets the Lock?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |