Humm, Markus wrote:

> The DLL has a data module which has one single TWSocket for all incomming
> data and for each outgoing connection a TWSocket is created dynamically.
> The instance of this socket is stored in a TObjectList together with
> other relevant information. 

Sounds like you re-invented TWSocketServer.

> When the first connection is opened a
> seperate thread within the DLL is created for handling of the windows
> messages (needed by TWSocket and other components as well).

I guess your listening socket runs in one thread and all client sockets
in a single second thread, do I understand that right?
> This works so far until the point is reached where the DLL is freed.
> The DLL is used statically in another DLL which has a thread for each
> connection too.

Hm, "too" sounds like each client connection runs in it's own thread?

This 2nd dll is loaded dynamically. When it is freed via
> free library, its finalization checks if there are any open connections
> thus threads) left. If yes, they all get freed and by freeing them each
> connection in the first dll should get closed too. 
> With TWSocket this doesn't work, because socket.close seems to hang and
> the 1st DLL never reaches the statement after the close.
> Pseudo code is like this:
> - write a marker to the windows eventlog (debug output)
> - call socket.close;
> - sleep(25);
> - write a marker to the windows eventlog (debug output)
> - call;

As Dod already said, using sleep with TWsocket is mostly not
suggested, since messages need to be processed. If you _must wait nevertheless, 
MsgWaitForMultipleObjects() may be an alternative.
However I haven't understood your DLL/thread design, and in which
threads your sockets run. If you don't get a better answer give
it another trial with a more detailed description of the thread
design and how sockets are created/attached to threads.

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to