Hi Marcus, I've been following your problem and I believe that the problem you have is because you are trying to use a dll with only a little multi-threading experience. One of the reasons people avoid threads is that it requires a lot of reading, development time, experience and when something goes wrong they are difficult to debug.
Have you built your DLL as a DLL or a COM-Object? Which threading model do you use? (Single, Free, Apartment or Both) How do you load the DLL? How do you reference the DLL? Does you design work as a normal application? The biggest question is why you need a DLL? Perhaps you could use a linked list or an array of client data to handle your instance connections to avoid threading. This might mean that you can get a working app quicker with fewer development problems. When you have a proof of concept/ working app then you can try to solve the problems that need to be solved using threads. Regarding multi-threading I always use "blocking" sockets for multi-threading and asynchronous sockets for single threaded applications. This is because I believe blocking sockets are easier to handle for threads since there is a single execution flow and you can restrict the cpu processing per thread using the timeout mechanism. Any errors can be easily handled with try..except blocks inside the execution handler. Are you sure that the ONLY problem you have is with the TWSocket.close and free? You might find more problems when you try more than one concurrent connection with different request data. You might want to try doing a peekmessage to clear the message queue of the thread before freeing the socket. Remember that the messages are trying to return to a handle that no longer exists which can cause access violations. I hope this all helps and good luck. Cheers, Jeremy Sargent. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
