For "actively calling CloseSocket()" and "passively noticing the socket has been closed",
we want to ensure that the process of closing a socket are the same. Therefore I use a
runnable to call CloseSocket() on the main thread when it can't read from the socket.
When closing a socket from within the main thread, we need to make
sure that the I/O thread does not operate on the related instance of
UnixSocketImpl.
With this patch, the main thread posts a SocketCloseTask to the I/O
thread. The SocketCloseTask removes the socket from the I/O thread's
list of watched file descriptors and dispatches an instance of
DeleteInstanceRunnable for the socket's UnixSocketImpl, which cleans
up the data structures. These steps serialize the close operation
within the I/O thread, and ensure that the main thread processed all
other dispatched runnables that may use the UnixSocketImpl.
The UnixSocketImpl currently polls the socket file descriptor while
listening for incoming connections and schedules itself to run again
if no connection requests have been received.
This behavior interferes with closing the socket and deleting the
socket structure in the main thread. It can happen that the I/O thread
dispatches a SocketAcceptTask to poll the listening socket and the
main thread dispatches a DeleteInstanceRunnable for the UnixSocketImpl,
such that the delete operation gets dispatched before the poll
operation. The latter then operates on the just deleted UnixSocketImpl.
With this patch, the I/O thread watches the listing socket for incoming
connection requests and only attempts to run accept when connection
requests are pending. This allows to serialize polling and close
operations within the I/O thread in a sound order.
A side effect of this patch is that we don't constantly run code for
polling the listing socket, which should result in less CPU overhead
and save battery power.
The Bluetooth system internally uses UnixSocketImpl when transfering
files. When Bluetooth gets disabled during a file transfer, the IPC code
deletes any related instance of UnixSocketImpl. This can happen before all
pending SocketReceiveTasks have been processed by the main thread. The
implementation of SocketReceiveTask uses a reference to the instance of
UnixSocketImpl that has just deen disabled. This results in a segmantation
fault.
This patch fixes the problem by scheduling the delete operation for
UnixSocketImpl to be executed after any pending SocketReceiveTasks.
