Merijin,
Apparently you have the very same problem as I do...
Try this fix to ICS library and see if the problem still persists (These
changes fixed my issue):
Inside routine "procedure TCustomWSocket.InternalClose(bShut : Boolean;
Error: Word)" I have added the following line:
WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle,
0, 0);
Just after
if FState = wsClosed then
Exit;
In my findings, even after closing the socket, winsock still sends
messages
to the registered handle (Registered by ASyncSelect), so, here I´m
telling
winsock to unregister all messages (As soon as socket is closed)
The source should be like:
if FState = wsClosed then
Exit;
WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0);
This is from TCustomWSocket.InternalClose
Try adding this line and see if the problem persists (Just for
testing), if
it fixes it will give more hints for Arno and François, because that
was how
I fixed my issue (Check on the newsgroup my message entitled: "Shared
handles problem". My issue is even worse because I use ICS shared handle
system everywhere that I need messaging, because ICS shared handle
approach
uses way less system resources!
Best Regards
Eric
-----Mensagem original-----
De: TWSocket [mailto:twsocket-boun...@lists.elists.org] Em nome de
Merijn
Bosma
Enviada em: sexta-feira, 31 de maio de 2013 12:46
Para: twsoc...@elists.org
Assunto: [twsocket] issues with wndcontrol's message dispatch mechanism
Hi all,
I think I've encountered an issue in the message dispatch system
which is
used by wndcontrol.
What I'm doing is creating and destroying some sockets:
- socket 1 registers message 1043 as FMsg_WM_ASYNCSELECT
(OverbyteICSWSocket:5696).
- this socket is free'd
- we start a server
- a client connects, so a new socket is instantiated (socket 2), which
registers it's FMsgRelease message (OverbyteICSWndControl:562), and also
gets 1043 for that message
- now it seems we get a WM_ASYNCSELECT for socket 1 (which was already
destroyed), which is now interpreted as WM_RELEASE for socket 2, so
socket 2
is destroyed silently.
We can reproduce quite reliably with the following setup
- create any server (TWSocketServer.Create();), no need to listen, just
instantiate
- create 5 sockets
- connect these sockets to 5 random ip's
- wait a few seconds
- destroy the 5 sockets
- start tcp server
- let a client connect.
The client will connect, and after approx 15 seconds it will drop,
caused by
the server dropping the socket due to above mentioned wrong interpreted
WM_ASYNCSELECT
We have reproduced this with both latest V7 and latest V8.
If I'm not mistaken and this is really the case, _and_ it's not
possible to
stop the WM_ASYNCSELECT from being send to us after the socket is
destroyed,
this seems to be quite a nasty problem to solve, since TIcsWndHandler
cannot
distinguish if a received message was meant for socket 1 (which is
already
destroyed) or for socket 2 (which reuses the particular message id).
An option could be to not recycle the message id's as soon as they are
available, but do a sort of circular buffer on them, hoping certiain
messages will not be received until they are really used again, this
doesn't
feel like a proper solution though and in that case the problem could
pop up
again when more sockets are used.
Arno, (I think you came up with the message dispatch approach), I'm
curious
to your thoughts and hope you (or we) can think of a good way to
tackle the
problem.
tia,
Merijn Bosma
--
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
