Hi Andy,
Thanks for your comments. The RFC proposes implementing missing features
of the current socket API for AF_UNIX sockets. It does not change any
aspect of the current API[1]. Your comments are about issues with the
current socket API and hence are not in the scope of this RFC. We can
work on a different RFC to address issues with the current socket API.
[1] The only feature missing in the RFC is delivery of urgent data
marker, RFC proposes to implement only the generation of SIGURG.
Delivery of the urgent marker was dropped based on internal feedback. I
am open to adding that to make the API comparable to TCP. Unlike TCP,
there is no ambiguity regarding the position of urgent byte for AF_UNIX
sockets, as the communication is between two sockets on the same system.
Currently the behavior is controlled via a configuration option, and
that option will apply to both sockets.
Regards,
Shoaib
On 11/28/20 8:02 PM, Andy Lutomirski wrote:
On Sat, Nov 28, 2020 at 7:07 PM <rao.shoaib@xxxxxxxxxx> wrote:
From: Rao Shoaib <rao.shoaib@xxxxxxxxxx>
We have a use case where thousands of processes connect locally to a
database and issue queries that are serviced by a pool of threads.
Communication is done over AF_UNIX sockets. Currently, there is no way
for the submitter to signal the servicing thread about an urgent
condition such as abandoning the query.
Sure there is. You could close() the socket. You could send() a
message saying that your query wants to be canceled. You could use a
second socket for this if it's somehow inconvenient to do it with a
single socket.
This patch addresses that
requirement by adding support for MSG_OOB flag for AF_UNIX sockets.
On receipt of such a flag, the kernel sends a SIGURG to the peer.
SIGURG is a horrible interface. It doesn't scale -- signals are slow,
and they give no indication of *which* socket has urgent data. Aside
from this, the "urgent" interface itself is nuts -- even the TCP RFCs
and implementations seem unable to agree on exactly how to tell
*which* data is urgent. At least epoll might be a scalable way to
tell which socket has urgent data, but that's not what your patch
description seems to be talking about.
Oh yeah, SIGURG simply doesn't work across privilege boundaries.
I'm also a bit nervous that there might be some program out there that
expects SIGIO but not SIGURG on unix sockets, and you're breaking
them.
--Andy
