>> 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.
Oh? And the other complaints haven't given you a clue?
We are a friendly community, and that includes choosing to follow
widely adopted threading conventions in order to make your readers
comfortable, instead of breaking them because you happen not to like
them. Please behave accordingly and don't be a jerk.
>> 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.
No, it means you cannot be notified of readability or writability,
they do not work with poll(). Sure, you have a flag that makes
them non-blocking, but to use it, you need to either loop around
it, which is polling (i.e. terrible), or to use another channel
for notifications. Which is what you are suggesting below:
>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.
Okay, so your IPC mechanism isn't just message queues, it's a mix
of two different channels: message queues *plus* signals. Signals
for notification, message queues for data transmission. Yes, it can
work, but it's more complex than it has to be, using two Unix
facilities instead of one. You basically need a small library for
the client side. Meh.
A fifo or a socket works as both a notification mechanism and a
data transmission mechanism, and it's as simple as it gets.
>and i have not even mentioned posix message queues which can be
>used from a select/poll based event loop ...
Yes, they can... but on Linux, they are implemented via a virtual
filesystem, mqueue. And your goal, in using message queues, was to
avoid having to mount a read-write filesystem to perform IPC with
process 1 - so that eliminates them from contention, since mounting
a mqueue is just as heavy a requirement as mounting a tmpfs.
Also, it is not clear from the documentation, and I haven't
performed tests, but it's even possible that the Linux implementation
of SysV message queues requires a mqueue mount just like POSIX ones,
in which case this whole discussion would be moot anyway.
>* 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).
You've lost me there. Why do you want several methods of IPCs in
your init system? Why don't you pick one and stick to it? Sockets
are available on every Unix system. So are FIFOs. If you're going
to use sockets by default, then use sockets, and you'll never need
to fall back on SysV IPC, because sockets work.
>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.
I have no idea what you are talking about.
> ^^^^^^^^^^ see ? how modern ? not that portable, right ?
> there was a reason why the initctl fifo was stored in /dev ...
Uh, yes, I'm writing an init system for 2019, not for 1992.
And *even* in 1992, there was a writable filesystem: /dev.
Now I'm not saying that creating fifos in /dev is good design, but
I am saying that if you need a writable place to create a fifo,
you always have one. Especially nowadays with /dev being a tmpfs,
so even if you're reluctant to mount an additional tmpfs at boot
time, you can always do stuff in /dev!
Needing a writable filesystem to create a fifo or a socket has
never been a serious limitation, and nowadays it is even less of a
limitation than before. The "must not use the filesystem at all"
constraint is artificial and puts a much greater burden on your
design than needing a rw fs does.
>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.
It's really not limiting, and the *only* correct behaviour.
The need to have a rw fs does not even come from the daemontools-like
architecture with a writable scandir. It comes from the need to store
init's logs.
Storing logs from an init system is not easy to do. Some systems,
including sysvinit, choose to not even attempt it, and keep writing
to either /dev/console (which is very transient and not accessible
remotely) or /dev/null. Some systems do unholy things with
temporary logging daemons. Daemontools (which needs a place to
write logs even though it doesn't naturally run as pid 1, and
doesn't assume that svscan's stderr points to something sensible)
does something that is better than /dev/null or /dev/console, but not
by much: it uses readproctitle, which reserves space in its friggin'
_argv_ to write rotated logs.
And some, including systemd of all things, do the right thing, and
actually realize that init's logs are *logs* and should be treated
as *logs*, i.e. stored and processed by a *logger program* in the
filesystem. And if there's no suitable filesystem at that time, well
they create one. Making a tmpfs is *easy*. And it's the only way
to get a unified log architecture.
>we use normal unix sockets on BSD
Oh, so it's not a problem to need a writable filesystem on BSD then?
So, why all the contortions to avoid it on other systems? If you're
fine with Unix domain sockets, then you're fine with Unix domain
sockets and that's it. And there's nothing wrong with that. And
you don't need a "portable backup/emergency method" - that just
bloats your init system for zero benefit. Z-e-r-o. Zero.
>why using semaphores ? they are primarily meant to ease the usage
>of SysV shared memory. but epoch init uses shared memory without them.
It is true that I didn't back my claim on this page that SysV IPCs
have terrible interfaces. At the time of writing, I had tried to
use them for an unrelated project and found them unusable; and in
10 years of auditing C code with heavy focus on IPC, I had been
submitted *no* code using them, so I thought my opinion was pretty
common. That was 7ish years ago. Since then, I have had to work with
*one* project using SysV message queues, and my initial impressions
were confirmed. I managed to make it work, but it was really
convoluted, and a lot more complex than it needed to be; it's
*definitely* not an IPC I would choose for a notification mechanism
for a supervision suite.
I don't know, something about only being usable for data transmission
and needing another IPC mechanism to the side for notification makes
me think it wouldn't be a good mechanism to use for notification.
I just have weird opinions like that.
--
Laurent
Received on Thu May 16 2019 - 21:25:09 UTC