(08-07-2018, 12:07 AM)kbriggs Wrote: All my VCL updates are done from the main thread, triggered via PostMessage. My Indy threads never touch UI components.
I wasn't necessarily suggesting that your server was touching the UI itself, just the UI thread. But OK, you use PostMessage() for that. Which HWND do you post to exactly? Hopefully to your own manually-created HWND and NOT to a VCL Form/Control's Handle property? Because the Handle property is not safe to access outside of the UI thread, even for something as "seemingly innocent" as (Send|Post)Message().
(08-07-2018, 12:07 AM)kbriggs Wrote: Not in this case. Clicking the "End Process" button on the Processes tab will knock the thread count from 11 or so down to 1 but that last thread will not die. Clicking End Process over and over again does nothing. Finding the thread in Process Explorer and trying to kill it there also does nothing. Rebooting is the only solution.
Can you run your server inside the debugger and still see the problem happen? TIdTCPServer names all of the threads that it creates, do you see the names appear in the debugger? Does the lingering thread have a name assigned?
Oh yeah, and attaching the debugger to a process and then killing the debugger is usually a good way to kill a process :-)
(08-07-2018, 12:07 AM)kbriggs Wrote: At 63K lines across 66 source files, that's probably not an option. It's also my flagship commercial product.
That is why I asked for a short demo that reproduces the same problem.
(08-07-2018, 12:07 AM)kbriggs Wrote: How do you do two-way asynchronous communication with TIdHTTPServer?
The same way you do it with TIdTCPServer. The trick is you have to keep your OnCommandGet event handler running for the lifetime of the websocket connection. Your OnCommandGet handler could negotiate the websocket handshake as needed, and then loop, processing websocket messages as needed until the client disconnects or the server is shutting down, and then exit. At least with using TIdTCPServer directly, it handles the loop internally for you, so you can focus on individual websocket messages per each invocation of the OnExecute event.

