Howard, are we suppose to be able to run two instances of dfGUI at once from the same directory??
Printable View
Howard, are we suppose to be able to run two instances of dfGUI at once from the same directory??
First of all you mean the DF Client not dfGUI. Technically no, it is possible to start two at the same time if you time it correctly but if you start one and wait a few minutes then try to start another you will get an error message from the second saying that the client is already started (it detects foldtrajlite.lock in the directory).
Since both clients would be trying to write filelist.txt and buffer files, my guess is that things would get messed up eventually.
Jeff.
OOPS, sorry D.P. ... should have had that cup of coffee first!
I haven't tried to test it again though so I don't know if it is a fluke or possibly something with the setting.
Actually both seem to run okay...I had them running for a whiles. I think they were actually on different data sets, not sure off-hand... good point though.
TTFN,
RS½
You can run two instances if you set up two directories, say one is distribfold and the other is distribfold2. Copy the files from distribfold to distribfold2 and then start the client in each directory. I do that with the multiprocessor systems I have.
Vic
I don't think he WANTS to run two instances from the same directory, he just did so and noticed that it worked (when it shouldn't). I think that the client just checks for the foldtrajlite.lock file like Jeff mentioned (I know that it DOES check for this, but it might check for more things also).
Well I wasn't able to produce, so if its a bug, its an obscure one... or just a fluke.
TTFN,
RS½
Howard,
I figured out what the bug is on having more than one instance launched from the same directory.
When you have a number of results buffered, and you set them to upload via dfGUI (i.e. press the upload button), apparently there is no .LOCK file during the upload and you are able to launch another instance of DF. dfGUI is not the problem as its just a convenient interface for monitoring/launching the client.
RuneStar½
There's no 'bugs', just don't run two copies in the same directory, it is not allowed. It is in the docs (albeit somewhat hidden, in the 'Windows service' section)
It may not be allowed, but I pulled it off as I noted. ;) If a user gets forgetful or a little happy on the clicking for launching DF, they'd have two (possibly more) instances running. During the first upload (if there are units buffered) when the client is launched, there is no .LOCK file so there is nothing to prevent two instances from concurrently running....
So although its not a good idea, it is possible to have at least two copies running at the same time this way. =)
RuneStar½
It's also possible to tie a lightning rod to your head during a thunderstorm and get hit by lightning, but it doesnt mean you should do it :bang:
I've noticed something similar to the following: When you use dfGui to stop the DF client, the DF client starts uploading, and then you can start a second DF client. When the first gets done uploading, they both stop.
Uploading in the background, so we don't lose those 2 mins during slow uploads on dialup would sure be nice. :)
Hey... you're the one that said its not allowed yet it was pulled off... and lightning rod only works if its grounded... so as long as you are not touching the ground..(Galoshes anyone?) you'd generally be okay.Quote:
Originally posted by Brian the Fist
It's also possible to tie a lightning rod to your head during a thunderstorm and get hit by lightning, but it doesnt mean you should do it :bang:
(yes, I am deliberately ignoring the point. ;) )
RS½
P.S. I like tpdooley's idea of background uploading. I don't think I've seen any D.C. client do that...
Lightning doesn't always hit the lightning rods atop the Empire State building (they have pictures of lightning hitting close to 1/2 way down the building)- and the lovely lady that got hit by lightning while standing in the bleachers of a stadium while watching a football/baseball game can testify to the fact that the highest object is not always hit (the lightning rods around the perimeter of the stadium didn't catch it.. nor did her taller neighbors..); 1 inch rubber soles are no protection to lightning. (what's the resistance of .. air? ;) and worst of all, she can attest to the joys of having 3rd degree burns caused by lightning heating up the metal in an underwire bra. (She's a one in a million/billion lady.. )
So betting on the "I'm shielded with rubber and near a lightning rod" isn't always going to save you.
(at least according to the program on the science channel.. which ruined my sense of safety.. and to think I was showing a lady from Florida that was lightning shy around Seattle - and told her we didn't need to hide.. the major buildings between 1st and Pine and the Space Needle would get it..)
Seti Client while using SetiStash Allows it. Its a nice feature, handy for dialup users like myself, but ulitmately you dont miss out on that much crunching.. generally to the upload...Quote:
P.S. I like tpdooley's idea of background uploading. I don't think I've seen any D.C. client do that...
the important number is not the resistance of air, but the electrostatic breakdown potiential (the maximum electric field it can withstand before it ionizes and you get a spark), which is about 30 kvolts/cm. And yeah, galoshes won't help you (especially if theyve got dirty water on them!)
Oh, and just to steer this post remotely in the direction of on topic: Probably the reason both clients stop when one is uploading, is that the foldtrajlite.lock file gets deleted. If you really want background uploading, it's pretty easy to just have a second DF directory that you can move all your bz2s and your filelist.txt to and upload from there. it's not any more difficult that going to the trouble of timing the startup of another client just right, anyway.