From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2599 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: emergency IPC with SysV message queues Date: Thu, 16 May 2019 17:15:55 +0200 Message-ID: <856441558019755@sas1-cd55e40a6ba0.qloud-c.yandex.net> References: <20190509071019.GE4017@panda> <7911341557578305@sas1-23a37bc8251c.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="178735"; mail-complaints-to="usenet@blaine.gmane.org" To: supervision@list.skarnet.org Original-X-From: supervision-return-2189-gcsg-supervision=m.gmane.org@list.skarnet.org Thu May 16 17:16:00 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 1hRI6y-000kM0-F0 for gcsg-supervision@m.gmane.org; Thu, 16 May 2019 17:16:00 +0200 Original-Received: (qmail 2554 invoked by uid 89); 16 May 2019 15:16:24 -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 2547 invoked from network); 16 May 2019 15:16:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1558019755; bh=r89XxufCY8k/qpvUmPj/eQPpgv/RQ/tIesH0wCax9j8=; h=Message-Id:Subject:In-Reply-To:Date:References:To:From; b=SCR8CQnmuuDMAlg32Bv75FXHwpwx44iDuFoc1U7LjqYTSK+1b50S6hFFeAnteoi07 hTwLLeXsvq4pLT5eoXynFAJwOe8vL93V39sK70oU/vvDNGYVyA/Ep1J7mJhuBlRgvp dBHarleykcKz9AuKboxVV2EVPjaFKJXrUoOTj+4g= Authentication-Results: mxback14g.mail.yandex.net; dkim=pass header.i=@yandex.com In-Reply-To: X-Mailer: Yamail [ http://yandex.ru ] 5.0 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2599 Archived-At: 11.05.2019, 15:33, "Laurent Bercot" : > 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) !!