AIUI, the parent and child processes are one and the same up the point of forking, so whatever "ownership" of the lock there is (if one can call it that) is held by both processes. But I think this is not the best way to think about it. The important thing is that the a file is marked by the OS as being locked (it doesn't matter by whom) so that other processes (those who are playing nice anyway) that attempt to get a lock while the first lock is in effect will use the failure inability to obtain the lock as an indication that they should wait because the file is "busy".
Update: Fixed the misleading wording (thanks to salva for pointing it out). Indeed, whether the request for the lock fails or blocks (both of which I'm referring to collectively as "inability to obtain the lock"), and ultimately the way the program "waits" until the file is no longer busy, depends on the specific arguments given to flock, as salva points out. And while I'm dotting my i's and crossing my t's, all of the above refers to Unix flocking. I know nothing about how any of this works on Windows.
the lowliest monk
In reply to Re: Fork + Flock = Who Gets the Lock?
by tlm
in thread Fork + Flock = Who Gets the Lock?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |