> I have an application that creates two clones using the clone() function
> with arguments sufficient to share all memory, etc... One clone then
> creates a file descriptor. The second clone then attempts to use that
> file descriptor, after having used an interlock to ensure that the
> variable holding the file descriptor has been loaded.
>
> What happens is that the second clone sometimes receives an invalid file
> descriptor error. However, if a delay slot is introduced in the second
> clone, such as a syslog message "I'm here!" in this case, the problem goes
> away. It's as if the kernel takes some time to propegate the process file
> tables, or else invoking a kernel call such as schedualing the I/O for
> the syslog message causes the tables to be refreshed so that the I/O on
> the target file descriptor can proceed when requested.
>
> Examination of the file descriptor variable before use in the second clone
> does verify that the clone interlock is working and that it is not being
> used un-initialized, even when the I/O request fails.
Most likely, it's a synchronization problem having to do with the compiler
not putting things where you think it's putting them. For example:
int interlock, fd;
void myfunction(void)
{
fd=open(/* something */);
interlock=1;
Sleep(250);
}
There is no guarantee that the result of the 'open' call will be written
back to memory before the value of 'interlock' is. It's entirely possible
that the value of 'interlock' will be written to memory before the call to
'Sleep' and the value of 'fd' will be written back only after 'Sleep'
returns.
So if another process does:
void myotherfunction(void)
{
while(interlock==0);
write(fd, /* some stuff */);
}
There is _no_ guarantee that the 'fd' it writes to will be the 'fd' that
resulted from the 'open' call above.
If you absolutely need things to happen in a particular order, you must
take steps to enforce it. Otherwise, all bets are off.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:25 EST