IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
deferred reply is short-circuited immediately when the file is
closed by another user, allowing it to be opened by the waiting user.
- added a sane set of timeval manipulation routines
- converted all the events code and code that uses it to use struct
timeval instead of time_t, which allows for microsecond resolution
instead of 1 second resolution. This was needed for doing the pvfs
deferred open code, and is why the patch is so big.
We found a few months ago that TDB_CLEAR_IF_FIRST is extremely
inefficient for large numbers of connections, due to a fundamental
limitation in the way posix byte range locking is implemented. Rather
than the nasty workaround we had for Samba3, we now have a single
"cleanup tmp files" function that runs when smbd starts. That deletes
the tmp tdbs, so TDB_CLEAR_IF_FIRST is not needed at all.
wakeup all pending locks at once. This change means that we only
trigger this anti-stampede code for write locks, as for pending read
locks the correct behaviour is to stampede (as they will all succeed)
want to expose the brl context structure outside the brlock.c
code. Instead, I now use "struct brl_context *" and rely on C being
happy to pass around pointers to unknown structures as long as they
are not dereferenced. I will be interested to see how the build farm
likes this.
This adds a pvfs_wait_message() routine which uses the new messaging
system, event timers and talloc destructors to give a nice generic
async event handling system with a easy to use interface. The
extensions to pvfs_lock.c are based on calls to pvfs_wait_message()
routines.
We now pass all of our smbtorture locking tests, although while
writing this code I have thought of some additonal tests that should
be added, particularly for lock cancel operations. I'll work on that
soon.
This commit also extends the smbtorture lock tests to test the rather
weird 0xEEFFFFFF locking semantics that I have discovered in
win2003. Win2003 treats the 0xEEFFFFFF boundary as special, and will
give different error codes on either side of it. Locks on both sides
are allowed, the only difference is which error code is given when a
lock is denied. Anyone like to hazard a guess as to why? It has
me stumped.
