I need some advise. Am I on the right track?
The code below dose not work as I would expect. If a thread is an
idependant path of execution should not the objects created on those paths
and imported on those paths be separate entities?
I need to load the same dll more that once. I want to avoid mucking with or
renaming files if it can be avoided. Gordon McMillan sugested possibly
using threads in a post on 4/20/99. Am I thinking this though properly?
The same library is being loaded on separate threads. When a thread is
spawned it gets its own copy of the interpreter state(yes?). But the
library for objects returned for separate threads is the same. Should not
each get its own?
One of the functions in the dll is EXPENSIVE. It's not mine and I doubt
they will rework it so I have to live with it. the EXPENSIVE function must
be called at the begining and ties all activity in the dll to a specific
directory. If you want to change directories you must call unexpensive then
EXPENSIVE again with the new directory as an argument. If the dll is loaded
and EXPENSIVE has been called sucessive calls to EXPENSIVE return FALSE.
I experimented with creating a copy of the dll with a diferent name and
loading it. This worked. I could call EXPENSIVE for the dll and the
copy_of_dll and both succeed.
Back to threads. First tryed using the windll module, but it caches the dll
in a module level variable so I didn't see that working so I tryed the
example below and it still doesn't work.
Any ideas, or a swift kick in the right direction is greatly appreciated.
Karl Putland
kperacles@geocities.com
***Begin Example***
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> class GMdll:
def __init__(self):
import calldll
self.calldll=calldll
self.handle=self.calldll.load_library('GM4S32.DLL')
self.h_load = self.calldll.get_proc_address(self.handle, "GMW_LoadBDE")
self.h_unload=self.calldll.get_proc_address(self.handle, "GMW_UnloadBDE")
def load(self):
from windll import cstring
s,g,c,u,p = map(cstring, ('d:\\goldmine',
'd:\\goldmine\\gmbase','d:\\goldmine\\demo','KARL','KAPPASIG'))
args=(s,g,c,u,p)
return self.calldll.call_foreign_function(
self.h_load,
'l'*len(args),
'l',
args
)
def unload(self):
return self.calldll.call_foreign_function(
self.h_unload,
'',
'l',
()
)
def die(self):
self.calldll.free_library(self.handle)
>>> from threading import *
>>> def test():
gm=GMdll()
lLock.acquire()
l.append(gm)
lLock.release()
>>> l=[]
>>> lLock=Lock()
>>> a=Thread(target=test)
>>> b=Thread(target=test)
>>> def tt():
a.start()
b.start()
>>> tt()
>>> l
[<__console__.GMdll instance at 839600>, <__console__.GMdll instance at
842910>]
>>> l[0].handle
22020096
>>> l[1].handle
22020096
>>>
The code below dose not work as I would expect. If a thread is an
idependant path of execution should not the objects created on those paths
and imported on those paths be separate entities?
I need to load the same dll more that once. I want to avoid mucking with or
renaming files if it can be avoided. Gordon McMillan sugested possibly
using threads in a post on 4/20/99. Am I thinking this though properly?
The same library is being loaded on separate threads. When a thread is
spawned it gets its own copy of the interpreter state(yes?). But the
library for objects returned for separate threads is the same. Should not
each get its own?
One of the functions in the dll is EXPENSIVE. It's not mine and I doubt
they will rework it so I have to live with it. the EXPENSIVE function must
be called at the begining and ties all activity in the dll to a specific
directory. If you want to change directories you must call unexpensive then
EXPENSIVE again with the new directory as an argument. If the dll is loaded
and EXPENSIVE has been called sucessive calls to EXPENSIVE return FALSE.
I experimented with creating a copy of the dll with a diferent name and
loading it. This worked. I could call EXPENSIVE for the dll and the
copy_of_dll and both succeed.
Back to threads. First tryed using the windll module, but it caches the dll
in a module level variable so I didn't see that working so I tryed the
example below and it still doesn't work.
Any ideas, or a swift kick in the right direction is greatly appreciated.
Karl Putland
kperacles@geocities.com
***Begin Example***
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> class GMdll:
def __init__(self):
import calldll
self.calldll=calldll
self.handle=self.calldll.load_library('GM4S32.DLL')
self.h_load = self.calldll.get_proc_address(self.handle, "GMW_LoadBDE")
self.h_unload=self.calldll.get_proc_address(self.handle, "GMW_UnloadBDE")
def load(self):
from windll import cstring
s,g,c,u,p = map(cstring, ('d:\\goldmine',
'd:\\goldmine\\gmbase','d:\\goldmine\\demo','KARL','KAPPASIG'))
args=(s,g,c,u,p)
return self.calldll.call_foreign_function(
self.h_load,
'l'*len(args),
'l',
args
)
def unload(self):
return self.calldll.call_foreign_function(
self.h_unload,
'',
'l',
()
)
def die(self):
self.calldll.free_library(self.handle)
>>> from threading import *
>>> def test():
gm=GMdll()
lLock.acquire()
l.append(gm)
lLock.release()
>>> l=[]
>>> lLock=Lock()
>>> a=Thread(target=test)
>>> b=Thread(target=test)
>>> def tt():
a.start()
b.start()
>>> tt()
>>> l
[<__console__.GMdll instance at 839600>, <__console__.GMdll instance at
842910>]
>>> l[0].handle
22020096
>>> l[1].handle
22020096
>>>