🚀 go-pugleaf

Bob,

Thanks for replying, I appreciate it.

Ok so let me try and clarify a bit more.

> You weren't clear if the "Clients" are just several threads in a
> single Process, or seperate Processes.

The Clients connect to a single process and each connection is a thread 
within the process.


> Multiple Threads within a single Process can access the same instance
> of the DLL. They will share the DLL, and all of it's data.
>
> As to "conflict", that depends on what sort of conflilct you are
> concerned about, and how the DLL was written.

So in my case it is necessary to have the data returned from the DLL be 
independent of any other thread calling the same procedure from the DLL. I'm 
almost positive the DLL is not written in a threaded manner.

So if I need to keep the data discrete between the multiple threads within 
my process is it acceptable to use the syncronize manner of accessing the 
DLL, or is there some other way for me to approach the problem.

Any additional help with this would certainly be appreciated.

Mike


"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:j8bm21hiql7v0dhlde0vaemcm7a10ib71m@4ax.com...
> mike wrote:
>
>>I have a central module into which multiple clients will connect via
>>blocking sockets. Each connection initiates its own socket class.
>
> You weren't clear if the "Clients" are just several threads in a
> single Process, or seperate Processes.
>
>>Now each client must get information by making a call to a DLL of which I
>>don't have control of, that is written by a third party. So my question is
>>do I have to load the DLL within each client connection in order to not 
>>have
>>any conflicts, or can I load the DLL once and have each client use the the
>>DLL without conflict.
>
> Each Process must load the DLL. Each instance will have it's own copy
> of the DLL's data.
>
> Multiple Threads within a single Process can access the same instance
> of the DLL. They will share the DLL, and all of it's data.
>
> As to "conflict", that depends on what sort of conflilct you are
> concerned about, and how the DLL was written.
>
>
>