In qb_ipcs_us_connect 4 files are created and bound.
I dont' know how this works for QB_LINUX or QB_CYGWIN.
But for the other OS the files are created and must be unlinked.
I use the same logic to construct the file names and unlink the files.
qb_ipcc_us_connect calls this
...
res = qb_ipc_dgram_sock_connect(r->response, "response", "request",
r->max_msg_size, &c->request.u.us.sock);
and qb_ipc_dgram_sock_connect calls
..
set_sock_addr
and in set_sock_addr the files are created if not Linux or Cygwin.
...
#if defined(QB_LINUX) || defined(QB_CYGWIN)
snprintf(address->sun_path + 1, UNIX_PATH_MAX - 1, "%s", socket_name);
#else
snprintf(address->sun_path, sizeof(address->sun_path), "%s/%s", SOCKETDIR,
socket_name);
#endif
...
We don't need to give the dispatch_add callback a reference
since the dispatch_del callback must occur before the
connection is destroyed. This extra reference counting
causes unnecessary complexity.
qb_ipcs_dispatch_connection_request is a callback function registered with
mainloop, or whatever other looping thread implementation is in use. When
this callback is registered, a reference of the connection object is given
to the mainloop thread. If this callback ever returns something none zero
the callback (and corresponding fd) is unregistered from the loop automatically,
so we must decrement the reference in this instance.
Since unregistering this callback from mainloop guarantees a disconnect
simply because requests on the fd are no longer processed, it is best
that we completely disconnect the connection (which will handle the unref)
when this callback returns an error... Otherwise since the fd is unregistered
from the mainloop thread, it may not be possible to detect a disconnect
in the future.
Seperate into a setup file and a socket backend file, it was getting messy
and confusing. Also preparing for using DGRAM sockets.
This should not result in any logical changes.
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
