While going through the shell extension part of TSVN to fix some wrong
guards against concurrent access to the shell extension part I found that:
1. critical sections aren't good enough to guard the cache. The reason
for that is that the cache is global in the COM dll and therefore used
by all processes concurrently. A mutex is needed to guard it.
You can easily try this out yourself: create a simple dll which only
shows a messagebox telling you the address of a dll global string. Then
create a simple exe which does nothing more than load this dll (make
sure it doesn't exit immediately so the dll stays loaded). Then start
the exe several times - each time you start the exe another process is
started and the dll is loaded into process space. But the dll tells you
the same address of the global string, no matter which process it has
been loaded from.
Since I've experienced crashs when just using critical sections I
started to wonder and used mutexes for some time now. But to be sure I
just wrote such a test dll and exe.
Another option would be to not make the cache dll global but a member of
the COM object class. But then each overlay (normal, modified, added,
removed, conflicted) and the column provider would each have their own
copies of the cache...
2. Will suggested to make the function GetCachedItem() private and just
expose GetFullStatus(). While this could be done, it would either mean a
performance decrease or getting rid of the "show folderstatus" setting
which I think should be left in TSVN so that people can speed up the
overlays some more while only loosing the overlays for folders, not files.
So what do you guys think? Should the GetCachedItem() function be made
private? Or should we just leave it like it is now?
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 6 19:29:01 2005