Francois - Im going to keep this short.
1) Messages date back to Windows before it could thread and were designed to allow cooperative multitasking in a single system thread.
2) ICS is built to its core around non blocking sockets using windows messages.
I did not say ICS could not work in a thread, but its clearly designed to work around messages which are designed for many sockets on one thread. Indy is specifically designed for threads. You have taken up a totally untenable position and for no apparent reason other than ego. The user is already using Indy internally. There is *no benefit* to using ICS in this specific situation and many drawbacks for no gain at all. You've literally chosen the one area where Indy clearly beats ICS without a doubt. They are both free products.
"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"
I'm not even going to go there. We've been down this route for decades. You are more than biased here and being disingenuous as well. Your statement is incorrect, but I simply dont have time to waste regurgitating it all yet again. If threads are that bad, then you might want to tell Microsoft and everyone else.
This is literally like trying to type Chinese on a English keyboard. Yeah, it can be dont but its not what the keyboard was designed for. Indy would work without *any prerequisites or patched methods*.... here are the steps to make Indy work in a thread:
1) Nothing.
With Indy there would be no forum post here at all asking "how do I make it work in threads".
Really you dont have anything better to do than fight over which free product a user should use especially when one is clearly better suited in a very specific situation and the user already is using Indy implicitly because IntraWeb is using it?
And you totally ignore things like deploying in IIS which doesnt offer the IntraWeb application a main application thread and in which there is no main thread message queue and permissions can even impact your ability to create one in some cases. And thread pooling, and thread ownership of the windows handles... the list goes on.....
When a user wants to handle multiple sockets on a single thread I recommend ICS, despite the fact that Indy CAN do that too. Why? Because Indy is designed for threads, an in that situation ICS is superior as it was designed for it. Neither ICS nor Indy are the magic solution for every situation.
Just let this thread pass. I'm sure you have something better to do with your time.
1) Messages date back to Windows before it could thread and were designed to allow cooperative multitasking in a single system thread.
2) ICS is built to its core around non blocking sockets using windows messages.
I did not say ICS could not work in a thread, but its clearly designed to work around messages which are designed for many sockets on one thread. Indy is specifically designed for threads. You have taken up a totally untenable position and for no apparent reason other than ego. The user is already using Indy internally. There is *no benefit* to using ICS in this specific situation and many drawbacks for no gain at all. You've literally chosen the one area where Indy clearly beats ICS without a doubt. They are both free products.
"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"
I'm not even going to go there. We've been down this route for decades. You are more than biased here and being disingenuous as well. Your statement is incorrect, but I simply dont have time to waste regurgitating it all yet again. If threads are that bad, then you might want to tell Microsoft and everyone else.
This is literally like trying to type Chinese on a English keyboard. Yeah, it can be dont but its not what the keyboard was designed for. Indy would work without *any prerequisites or patched methods*.... here are the steps to make Indy work in a thread:
1) Nothing.
With Indy there would be no forum post here at all asking "how do I make it work in threads".
Really you dont have anything better to do than fight over which free product a user should use especially when one is clearly better suited in a very specific situation and the user already is using Indy implicitly because IntraWeb is using it?
And you totally ignore things like deploying in IIS which doesnt offer the IntraWeb application a main application thread and in which there is no main thread message queue and permissions can even impact your ability to create one in some cases. And thread pooling, and thread ownership of the windows handles... the list goes on.....
When a user wants to handle multiple sockets on a single thread I recommend ICS, despite the fact that Indy CAN do that too. Why? Because Indy is designed for threads, an in that situation ICS is superior as it was designed for it. Neither ICS nor Indy are the magic solution for every situation.
Just let this thread pass. I'm sure you have something better to do with your time.