> On Dec 7, 2020, at 8:35 AM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Sat, Nov 28, 2020 at 08:02:37PM -0800, Andy Lutomirski wrote: >>> On Sat, Nov 28, 2020 at 7:07 PM <rao.shoaib@xxxxxxxxxx> wrote: >>> 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. > > The application already works with SIGURG (and TCP, obviously). Yes, > it could be changed to use one of these other methods, but they're all > more inconvenient to use than SIGURG. > >>> 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. > > It doesn't need to scale. This is "client wishes to abort the operation", > just like telnet. Each thread only has one socket (and, thanks to > F_SETOWN_EX, signals for that socket get directed to that thread). > Oh, you have thousands of clients and each client has its own server thread. Lovely. >> 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. > > That doesn't matter. Unix sockets with MSG_OOB behave like they > have had SO_OOBINLINE which is the recommendation from > https://tools.ietf.org/html/rfc6093 Fair enough. > >> 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. > > epoll is the wrong interface for this application, as far as I can tell. > >> Oh yeah, SIGURG simply doesn't work across privilege boundaries. > > Please elaborate. SIGURG is default-ignore, so you have to enable a > handler for it. And you have to call SETOWN to receive a signal. > >> 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. > > The only incompatible scenario I've been able to think of is an > application which has both TCP and Unix sockets will suddenly get its > SIGURG handler called for Unix sockets when it's only expecting to get > it called for TCP sockets. That feels like a very unlikely scenario. So maybe this is okay. It does seem like a hack, but maybe it’s a hack that’s not too bad to support in the kernel.
