Olivier Sannier wrote:
>> Thanks for the information. I did moved to v6 and had to adapt a few
>> things (would have been nice if Disposed in TIcsWndControl had been
>> protected and not private) but it did not help at first.
>> Why?
>> Because as soon as all connected clients would disconnect, the handle
>> allocated for them would be released. And the next time a client
>> comes in, the handle cannot be created anymore because the Indy part
>> of the process has taken it.

How comes that this part grabs any handle and does not cause an
'out of handles' error itself? Do you use a thread pool that never
shrinks? How many client connections are served when the error happens?

>> What I did was to instantiate a dummy TIcsWndControl component per
>> message pump thread instance, attach it to the thread and only
>> release it when the thread ends.
>> Then I made the threads start at the beginning of the process
>> instead of "on demand". There are only two of those threads, so
>> that's not too much of a hassle.
>> This way the handle is created at the very start, when there are
>> still handles left for the process and is never released even if all
>> clients disconnect.
>> 
>> Note that I created a dummy "TIcsWndControl" instance as it seems the
>> easiest way to do keep the handle opened, if you know of a better
>> way, please let me know.

It's a workaround only, since one hidden window can handle a maximum
number of const WH_MAX_MSG = 100 registered message IDs only, hence it
won't prevent ICS from creating new hidden windows on demand depending
on the number of concurrent client instances. 

--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html

-- 
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