[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 13/14] raw-posix: Implement image locking
From: |
Fam Zheng |
Subject: |
Re: [Qemu-block] [PATCH 13/14] raw-posix: Implement image locking |
Date: |
Wed, 18 Jan 2017 21:19:00 +0800 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Wed, 01/18 14:02, Max Reitz wrote:
> >> Testing whether something is locked would be easier by using F_OFD_GETLK
> >> instead of actually creating an exclusive lock and then releasing it.
> >
> > My attempt to do this shows it doesn't work: fcntl forces the tested lock
> > type
> > to read lock for some unknown reason, so it cannot be used to test other
> > shared
> > lockers.
>
> Do you have a reproducer? The attached quick and dirty test case works
> for me (compile test.c to test and test2.c to test2), producing the
> following output (when running ./test):
>
> set rd lock: 0, Success
> get lock: 0, Success; read lock in place
> set wr lock: -1, Resource temporarily unavailable
> unset lock: 0, Resource temporarily unavailable
> ===
> unset lock: 0, Success
> get lock: 0, Success; unlocked
> set wr lock: 0, Success
> unset lock: 0, Success
> ===
> set wr lock: 0, Success
> get lock: 0, Success; write lock in place
> set wr lock: -1, Resource temporarily unavailable
> unset lock: 0, Resource temporarily unavailable
You are right, now I see why I was confused with the F_OFD_GETLK interface.
Fam
>
> So the l_type field is correctly set after every F_OFD_GETLK query call.
>
> Max