>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).
--
francois.pie...@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
--
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
