SocketHandler has been renamed to TCPSocketHandler
SocketHandler is now a simple interface with a few methods, used only by
Poller.
This way we can inherite from the new SocketHandler class, to handle other
types of sockets, and still make them manageable by the poller without any
change in the Poller class.
Was causing the event to not be removed in case of connection failure, which
lead to a dangling timed event named “timeout-1”, which was called later, by
some other SocketHandler for which even the socket creation failed (so, its
socket is -1), with a pointer to the previous SocketHandler which has
disappeared for a long time: segmentation fault etc.
Since the socket is now only created and managed whenever the connection is
being established, we only close the socket and if it was created (we use -1
to denote the fact that is not yet created, or has been closed) and we only
unmanage the socket if it is effectively managed.
fix#2529
We want to call socket() with the parameters provided by getaddrinfo, so we
can’t addd the fd into the poller immediately. We need to wait the
connection attempt, and then the SocketHandler can call add_socket_handler
itself, if the connection succeeds, or is in progress.
Because the read handler may discover that the connection has been closed,
and then remove the socket from the poller. It that case it is no longer
valid to try to call the write handler (which may try to reconnect, but
since that socket is no longer managed, this is not OK).
Apparently on some systems, subsquent connect() calls may fail with EISCONN
error, to indicate that the connection succeded in the background, instead
of returning 0.
(that is, the read/write/connect/etc)
Because this code is actually common for both the IrcClient and
XmppComponent class. These two classes have to implement some higher level
callbacks (parsing the data provided in the buffers, doing stuff when the
connection is done) instead of doing the read/write/connect low level
things.
Florent Le Coz