Rickey, Kyle W wrote:
> I'm trying to get the file version of an executable file on our network.
> At times our network is quite slow, so to prevent blocking of my main
> application, I decided to put the code into a separate thread.
> 
> Depending on the network speed, it can take up to 30 seconds to return.
> This is because of a vpn connection etc.
> 
> But when put in a separate thread, it will block the entire application
> until the function returns. Take the following code for example:
> 
> import threading, time, os, win32api
> 
> file = r"\\network_share\file.exe"
> 
> def get_version_number():
>       if os.path.exists(file):
>               info = win32api.GetFileVersionInfo(file, "\\")
>               ms = info['FileVersionMS']
>               ls = info['FileVersionLS']
>               return win32api.HIWORD(ms), win32api.LOWORD(ms),
> win32api.HIWORD(ls), win32api.LOWORD(ls)
>               
> def test():
>       print ".".join([str(i) for i in get_version_number()])
> 
> print "AA"
> threading.Thread(target=test).start()
> while 1:
>       print "AA"
>       time.sleep(0.5)
> 
> The output looks like this:
> 
> AA
> AA
> 2.0.0.15
> AA
> ..
> 
> The problem is after those 1st to "AA"'s got printed, no more were
> printed until the version number came back. Any ideas why this is
> happening?
> I've got python 2.5 and pywin32-210.

Works for me with the same setup. I stuck a time.sleep into the
test function to simulate the slowness of your network. Might make
a difference, I suppose. Couple of tangential points:

1) If you're on a slow connection anyway, don't have the double-whammy
of checking the file's existence and then fetching its version info. Just go
for the version info and catch the exception. CAVEAT: The exception seems
to be identical for a non-existent file and a file with no version info.

2) [This may just be because this is self-contained sample code]
You're generally going to be better of using a Queue or something
suitably locked sharing mechanism to get info to and from a thread.

I can't see anything else obvious. Do you see the same behaviour with
a local drive and a faked delay, eg time.sleep (5)? If not then it might
be that the various levels of your network setup are conspiring to block
the process. Not really sure there. If that does prove to be a showstopper,
you might consider the  processing module which is plug-compatible with
threading but uses processes instead. Bit of a sledgehammer to crack a
nut, maybe but...

TJG
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32

Reply via email to