Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hello !
Regarding my previous post about leakings locks - I think I found the
reason.
current HEAD version.
Files are locked in rcsbuf_open() before trying to open them.
If file is not found (I actually have no ".directory_history" files in
my repository) this function returns 0.
The rcsbuf_open() is called for example from RCS_parsercsfile_i:
if(!rcsbuf_open(&rdata->rcsbuf, rcsfile))
{
TRACE(3,"rcsbuf_open failed");
xfree(rdata->path);
xfree(rdata);
return NULL;
}
File not existing in repository remains locked !
All this locks are unlocked when client disconnects from the
lockserver. But with large number of directories number of such locks
can be significant (I got about 2 thousand of them with project having
about 300 directories - this is java project so each package is a
separate directory).
With two concurrent updates on such project number of locks in the
internal lock server list will be 4 thousands and so on. The whole
list is scanned for each lock.
How this can be solved:
1. Unlock each file after they are locked.
2. Use map instead of list in the lock server.
The best way is to implement both.
I can modify lock server and test it on windows when I have time.
Should I ?
--
Best regards,
Alexey mailto:alexey-panchenko at hotmail.ru