>You get the best isolation from
the host application by creating a worker thread and run most of your code
in the context of this thread.
Okay, I think I got the structure which seems correct.
As I need several sockets for several purposes, I can't use socket's message loop (I don't want to create all of them on DLL load). And I export several functions
each of them uses its own socket.

A single thread is able to handle a lot of sockets (I have applications handling hundreds of sockets per thread). I think you should use only one thread for all socket operation within your application and one thread for each lengthy processing/computation you have to do. The rule is to avoid lengthy processing within the thread doing communication.

* return appropriate socket (create and init it if necessary, attach to the thread with ThreadAttach - I can't create them inside Execute because it's more complicated with my design).

In my opinion, you should revise you design to better fit the programming model used for ICS. Otherwise you'll end up with a complex application difficult to maintain a prone to errors.

to avoid socket events outside the DLL functions — or maybe I just may pause all the sockets?

Sockets events are always triggered in the context you the thread having created the socket or the trheaded haing the socket "attached". You should probably not call host application code from another thread than the one active at the time of the call to your DLL. This require some inter-thread communication and synchronization. This will result of more complex code in your DLL with the advantage of maximum isolation of the hosting application. This is important if you have no control on the hosting application and you don't know how it is working internally.

Questions are:
1) How to avoid socket events outside the DLL functions (I guess pausing/resuming the sockets is better cause I'll only have one active socket at a time — the one I need)

See above. Pausing/resuming the socket shouldn't be used, specially if you have your own worker thread. Just have the socket event handler blocked waiting for some synchronization object.

2) Do I have to do socket.ThreadDetach on app closing or it's OK?

Yes, you have to detach the socket from the worker thread before destroying the socket. As I said before, you can avoid thread Attach/detach with careful design. Having to use attached/detach is the sign of a too complex design.

Always apply the KIS principle (Keep It Simple).

The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)

To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to