From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2582 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: emergency IPC with SysV message queues Date: Sat, 11 May 2019 13:34:22 +0000 Message-ID: References: <20190509071019.GE4017@panda> <7911341557578305@sas1-23a37bc8251c.qloud-c.yandex.net> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="78028"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.34711.0 To: "supervision@list.skarnet.org" Original-X-From: supervision-return-2172-gcsg-supervision=m.gmane.org@list.skarnet.org Sat May 11 15:33:40 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hPS8A-000KBB-MN for gcsg-supervision@m.gmane.org; Sat, 11 May 2019 15:33:38 +0200 Original-Received: (qmail 9284 invoked by uid 89); 11 May 2019 13:34:03 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 9277 invoked from network); 11 May 2019 13:34:03 -0000 In-Reply-To: <7911341557578305@sas1-23a37bc8251c.qloud-c.yandex.net> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2582 Archived-At: 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 indirec= tly >(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