I have been loosely following the Explorer hangup thread. For some, it
must run close to being a show stopper for using Will's fast cache.
Keeping fingers crossed, it hasn't happened to me as yet.
Consequently, I keep feeling that maybe it's Dependant on individual
users hardware and or software configuration.
So I' start by describing my "medium performance system" here.
Working copies from 35 versioned projects are held in C:\Delphi, each in
separate folders mirroring their repositories. The largest repository
contains vendor code such as TMS components, AsyncPro and a few others.
Whilst there isn't a heavy load on TSVN itself in terms of checking
files in and out, committing etc, the folders are opened and closed many
many times per day so Explorer, and the calls into TSVN to populate
folder Icons are being heavily exercised.
The repositories are held on a remote NT server, accessed via Apache
2.0.53 and SVN 1.1.3.
TSVN 1.1.3 (Build 2923) is running on a 1.5 GHz AMD box with 750K ram on
fully patched Win2K.
The anti virus is Computer Associates VET.
I use Outer Technologies Cacheman 5.11
In idle periods Executive software's Diskeeper 9 looks after the hard
drive file fragmentation and occasionally I run it to defragment the
meta file data and pagefile.
Registry Mechanic keeps registry loose ends to a minimum and there are
no unwanted spyware "nasties" running.
Interbase is installed but is not used.
So that if you like is a baseline for a system that hasn't experienced
an Explorer hangup, yet!
Experience gleaned from participation in a team doing a multi threaded
communications project a few years ago may be of relevance here.
There were three kinds of hard to track down problems we needed to keep
on top of.
1 Race conditions.
2 Resource deadlocks
3 Memory leaks
3 Callbacks to vaporised code (destroyed objects)
Race conditions were prevented by designing the structure carefully.
Resource deadlocks were prevented by using some very well conceived and
well written thread safe base objects.
Memory leaks. Whilst the project wasn't COM based, it made heavy use of
Delphi's interfaces which when not fully released gave us dreadfull
memory leaks but these didn't contribute to crashes.
The last, (callbacks to vaporware) however really got us by the short
and curlies, many times, particularly from timers firing off when the
object of it's desire had already gone to God.
Trying to apply an OCCAM's RAZOR approach then:-
If the machines suffering problems are much faster or slower than mine,
then maybe its a speed thing and as such, most likely a race condition.
If they are of similar speed, then what is different? Working copy size
and folder depth, low free ram or poor HDD access times due to bad
defragmentation. My only large WCs are in the vendor code folders.
If none of the above then it might be worth doing an inventory of shared
resources( mutexes etc) and have a close look at the edge conditions for
their access.
Lastly but not necessarily least likely, are all hooks and callbacks
released. Are they blindly overwritten when already "owned" by other
code?. Are the installation and release of callbacks synchronized
through a central point to ensure the process is properly sequenced and
thread safe?
I'm barely c literate and don't have an environment to go looking at
code, let alone any knowledge of interacting with shell extensions so
don't count on me there. I just wanted to establish a point of "working
for me" reference that may be of use to developers.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Mar 30 03:32:03 2005