Re: emergency IPC with SysV message queues

From: Jeff <sysinit_at_yandex.com>
Date: Thu, 16 May 2019 17:15:55 +0200

11.05.2019, 15:33, "Laurent Bercot" <ska-supervision_at_skarnet.org>:
> Please stop breaking threads. This makes conversations needlessly
> difficult to follow, and clutters up mailboxes.

i do that intentionally since i find the opposite easier to follow.
that leads often to complaints on other lists aswell.

> That is obviously not going to work.

obviously ? to me this is not obvious at all.

> Operations such as msgsnd() and msgrcv() are synchronous and
> cannot be mixed with asynchronous event loops.

what does that exactly mean ? do you mean they block ?
this not the case when the IPC_NOWAIT flag is used.

> There is no way to be asynchronously notified of the
> readability or writability of a message queue, which would be
> essential for working with poll() and selfpipes for signals.

i do not understand at all what you mean here.
the client should signal us (SIGIO for example) to wake us up, then
we look at the input queue without blocking (handling SIGIO via selfpipe)
else we ignore the msg queue. again: this just a backup ipc protocol.
i suggest not to use an output queue to reply to client requests, keeps
things simpler. but if you insist on a reply queue you have to look if it
is not full before writing the reply to it (do this with a non-blocking call
to msgrcv(2) using said IPC_NOWAIT flag). use IPC_NOWAIT in the
following msgsnd(2) writing call, again nothing will block.

and i have not even mentioned posix message queues which can be
used from a select/poll based event loop ...
(dunno if OpenBSD has them)

please also take into consideration the following:

* we run as process #1 which we should exploit (SysV ipc ids) here

* SysV ipc is just used as a backup ipc protocol where unix (abstract
  on Linux) sockets are the preferred default method
  (and signals of course).

> If you are suggesting a synchronous architecture around message
> queues where the execution flow can be disrupted by signal handlers,
> that is theoretically possible, but leads to incredibly ugly code
> that is exceptionally difficult to write and maintain, to the point
> where I would absolutely choose to use threads over this.

just a claim, it is not too much work, now that you beg for it i consider
adding it again, just for you as i would else have restricted myself to
signal handling only which is absolutely sufficient in that case.

> Yes. Every modern Unix system has a way to create and mount a RAM
                     ^^^^^^^^^^ see ? how modern ? not that portable, right ?
                     there was a reason why the initctl fifo was stored in /dev ...

> filesystem. The APIs themselves are not portable, and that is why
> s6 doesn't do it itself, but the concept totally is. If I had more
> experience with the BSD APIs, I could easily port s6-linux-init to
> the BSDs. I hope someone more BSD-savvy than me will do so.

no this is not portable but your assumption since s6 will not work
without rw which is indeed very limiting and far from correct behaviour.
the need for rw is an unnecessary artificial introduction to use your
daemontools style supervisor tool suite for process #1.

> Using non-portable *functionality*, on the other hand, is an
> entirely different game. Abstract sockets only exist on Linux, and
> porting code that uses abstract sockets to another platform, without
> using non-abstract Unix domain sockets, is much more difficult than
> porting code that mounts a tmpfs.

we use normal unix sockets on BSD, on Solaris one could also use SysV
STREAMs for local ipc (needs also rw AFAIK).

that is ok since we provide a portable backup/emergency method that
works even on OpenBSD. on Linux we exploit its non-portable abstract
sockets which makes ipc even less dependent on rw mounts.
that is perfectly ok IMO.

> That is my opinion backed by 20 years of experience working with
> Unix systems and 8 years with init systems, and evidence I've been
> patiently laying since you started making various claims in the mailing-list.

it is you who makes claims on your web pages, so i just wondered how
you back them. quote:

> System V IPCs, i.e. message queues and semaphores.

why using semaphores ? they are primarily meant to ease the usage
of SysV shared memory. but epoch init uses shared memory without them.

> The interfaces to those IPCs are quite specific and can't mix with

specific to what ? even older unices support them.
and SysV shared memory is in fact a very fast ipc method.

> select/poll loops, that's why nobody in their right mind uses them.

there exist also the respective successor posix ipc mechanisms
where one could do exactly that.

> You are obviously free to disagree with my opinion,
> but I wish your arguments came backed with as much evidence as mine.

they are backed very well by the man pages of the syscalls in question.
please also notice the difference between an ipc mechanism and a
protocol that makes use of it.

>> (hello opendir(3) !!! ;-). :PP

hello (pu,se)tenv(3) !!
Received on Thu May 16 2019 - 15:15:55 UTC