🚀 go-pugleaf

mike wrote:

>> 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.

Still not clear. Are you saying there are several Client processes
connecting to a single Server process that is multi-threaded?

And, is it the Clients that use the DLL or the Server?

>> 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.

If the DLL hangs on to the data, or is "statefull" (remembers what it
is doing), then all threads will see the same state/data, and you will
likely have problems using it multi-threaded.

>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.

If the DLL hands you the data, and then doesn't remember it, then yes,
you can save the data in your thread (local stack variable). And, if
the code isn't reentrant, then I suppose some locking mechanism is in
order.