On Sun, May 27, 2012 at 12:33 AM, Wanlong Gao <[email protected]> wrote:
> On 05/26/2012 10:15 PM, Garrett Cooper wrote:
>
>> The testcase tests to see whether or not locks are successfully
>> inherited across forking processes, as the requirements for fork state
>> that they should not be. The problem is that the test tests the negative
>> case for ftrylockfile (!= 0) instead of the positive case, which creates
>
> The ftrylockfile() function returns zero for success (the lock was obtained),
> and nonzero for failure.
> So I think the origin is right.
My description might be wrong, but the fix is right. ftrylockfile
should fail in the testcase (not succeed) because the file lock isn't
owned by the forked process. It succeeds simply because the delay is
long enough on some platforms. I could check and ensure that EAGAIN
(or the POSIX prescribed error) occurs if this occurs instead in the
implicit else case.
Thanks!
-Garrett
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
