Please stop breaking threads. This makes conversations needlessly
difficult to follow, and clutters up mailboxes. Your mailer certainly
has a "Reply" or a "Reply to group" feature, that does not break
threads; please use it.
>that is wrong. just read the msg queue when a signal arrives
>(say SIGIO for example). catch that signal via selfpiping and there
>you are, no need to use threads.
That is obviously not going to work. Operations such as msgsnd() and
msgrcv() are synchronous and cannot be mixed with asynchronous event
loops. 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.
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.
Interruption-driven code was common in the 1990s, was a complete
nightmare, and thankfully essentially disappeared when Linux
implemented a half-working threading implementation. I would not
trust myself to write correct interruption-driven code, let alone
make it readable by other programmers. You should not trust yourself
either.
>> Every modern Unix can mount a RAM filesystem nowadays,
>that is a poor excuse, you wanted to portable, right ?
Yes. Every modern Unix system has a way to create and mount a RAM
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.
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.
>use the console device for your early logs, that requires console
>access though ...
I said *logs*, as in, data that can be accessed later and reused,
and maybe stored into a safe place. Scrolling text on a console is
no substitute for logs.
>that is just your opinion since your solution works that way.
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. You are obviously free to disagree with my opinion,
but I wish your arguments came backed with as much evidence as mine.
>you can tell a reliable init by the way it does ipc.
>many inits do not get that right and rely on ipc mechanisms that require
>rw fs access. if mounting the corresponding fs rw fails they are pretty
>hosed since their ipc does not work anymore and their authors were
>too clueless to just react to signals in case of emergency and abused
>signal numbers to reread their config or other needless BS.
>
>i top my claims even more:
>you can tell a reliable init by not even using malloc directly nor indirectly
>(hello opendir(3) !!! ;-). :PP
Every piece of software is a compromise between theoretical minimalism
/ elegance and other requirements. Even minimalism and elegance are
sometimes subjective: my position is that using s6-svscan as process 1
is more elegant than having a separate "minimal" process 1 that still
needs to perform some kind of supervision, because writing the separate
process 1 would lead to some functionality duplication and also add
more code. Your opinion is obviously different; instead of taking cheap
shots, show me the code, and then, maybe, we can compare merits.
--
Laurent
Received on Sat May 11 2019 - 13:34:22 UTC