This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Feb 15 14:14, David Rothenberger wrote: > On 2/15/2012 1:20 PM, Corinna Vinschen wrote: > > On Feb 15 13:15, David Rothenberger wrote: > >> On 2/15/2012 12:45 PM, Corinna Vinschen wrote: > >>> On Feb 15 11:39, David Rothenberger wrote: > >>>> But... now one of the flock tests is failing. It takes a while to > >>>> extract a STC from the APR test suite because everything is written in > >>>> APR-ese and I have to convert every APR call into the base C library > >>>> calls. I'll work on that over the next day or three. > >>>> > >>>> The gist of the test that's failing is this: > >>>> > >>>> * Create a file. > >>>> * Get an exclusive flock on it. > >>>> * Spawn a child process that attempts to get an exclusive, non-blocking > >>>> lock on the file. > >>>> > >>>> The test is expecting that the child will not be able to get the lock, > >>>> but the child is able to. > >>>[...] > >>> Does it fork/exec or does it only exec? > >> > >> Looks like fork/exec. execv to be precise. > >> > >>> I guess I really need the testcase. > >> [...] I read the Linux man page again (http://linux.die.net/man/2/flock) and I just hacked the following testcase, based on your flock STC. It creates a lock in the parent, then forks a child. The child tries to grab the lock, first using the inherited file descriptor. This is supposed to work. Then it opens the file again and tries to lock the file using that descriptor. This is supposed to fail with EWOULDBLOCK. If it failed to lock the file one way or the other, it tries to unlock the file using the second descriptor. In theory this should fail. If it doesn't fail, it tries to lock the file again using both descriptors. The expected result is the same as in the first two tries. Eventually the child exec's, and runs the entire set of tests again. The result should be the same as for the forked child. I tried this test on both, Linux and Cygwin (latest from CVS), and it behaves identically: Linux$ ./stc-flock-forkexec funlock from forked child with new descriptor succeeded but shouldn't funlock from execed child with new descriptor succeeded but shouldn't Cygwin$ ./stc-flock-forkexec funlock from forked child with new descriptor succeeded but shouldn't funlock from execed child with new descriptor succeeded but shouldn't Funny enough, unlocking always returns success on the descriptor not holding the lock, even on Linux. But the second set of tests shows that the lock is still firm in the hands of the first descriptor. The testcase is attached. I'm pretty curious what your test is actually testing. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Attachment:
stc-flock-forkexec.c
Description: Text document
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |