Quote:ICS uses messages which do NOT work in threads.
That is completely false. Read
Microsoft documentation.
Quote:Francois even tells you this in his first message.
That is not what I said. I said that ICS make use of messages and the thread using ICS must have a message pump.
Quote:Using ICS in a threaded application is a fools errand.
That is completely stupid. Im being as kind as I can.
Quote:ICS is a fine product, but was never designed for threads.
ICS has been designed to be also used with thread. Since ICS is non blocking, a single thread is able to handle hundreds of communications simultaneously. You only need to use multi threading if your application code is blocking (For example, some database components are not asynchronous so you must use a thread while lengthy SQL request is running).
Another use case is when you have to handle THOUSANDS of simultaneous, active communications, then use a thread for each 500 connections.
Using thread for each connection is NOT recommended at all, it is a large waste of resources and that is what Indy is doing. Bad.
Of course ICS may also be used with a thread for each connection if you like to waste resources. Those thread need a message pump as explained in
Microsoft documentation.
Quote:AllocateHWnd is not thread-safe. This has been known for a long time now.
ICS has his own AllocateHWnd method that is thread safe. It make use of a critical section to protect the class registration (GetClassInfo and RegisterClass) and then use CreateWindowEx to create the handle. For those interested, look at TIcsWndHandler.AllocateHWnd in unit OverbyteIcsWndControl.
Additionally, TWSocket has two methods ThreadDetach and ThreadAttach to move the messages from one thread to another. For example you may have a thread to run the listening server socket and one other thread to handle client socket (That is what Indy is doing). The server thread create the client socket and - if you like - you can detach it from that thread and attach it to another one.
Quote:He's using an Indy-based IntraWeb server. He creates a window handle when his application is receiving an incoming request. The Indy HTTP server spawns a worker thread which is freed afterward. The window handle is released when the thread is destroyed. Then he tries to use the same window handle in a subsequent request, from another thread (there is no guarantee that the original thread which created the window handle hasn't been destroyed).
This is exactly the kind of use case where ICS TWSocket.ThreadDetach and ThreadAttach are made for. Of course this doesn't remove the need for a message pump. TWSocket also has a method which is a message pump so that when a thread has no message pump, this method can be used until the communication is closed.
Finally, as I said in my first reply to the original discussion, it is simpler to put all ICS stuff in a single thread created from the IntraWeb thread handling the client.