From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a52626a9019b830 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.107.167 with SMTP id hd7mr824915wib.0.1347644542220; Fri, 14 Sep 2012 10:42:22 -0700 (PDT) Path: ed8ni64780411wib.0!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Help writing first daemon Date: Sat, 8 Sep 2012 10:06:17 +0200 Organization: cbb software GmbH Message-ID: <1hrmrgblczf2p.x7ar7hqalypi.dlg@40tude.net> References: <3b3a796d-50e0-4304-9f8d-295fb2ed0e82@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-09-08T10:06:17+02:00 List-Id: On Fri, 7 Sep 2012 15:05:52 -0700 (PDT), Patrick wrote: > I am setting out to write my first daemon. There seems to be a lot of > options for inter-process communication on posix systems. I am planning on > designing a scientific instrument control server that will control ports, > like the serial port, based on signals it is sent. It will also collect > data from instruments and store the data(I was thinking in a postgresql > database). Process automation middleware is much work. > I just need signals passed on one machine so yaml4 seems like overkill. I > was thinking that I could write many little commands, with each command > specific to an instrument it is designed to control and the daemon as more > general infrastructure(basically middleware), so it wouldn't really be a > parent/child relationship. I'm guessing plain old pipes are out. Pipes could serve as a transport for the middleware, which could run its publisher/subscriber services on top of them. But, if you consider running the middleware as a system service (daemon), the main reason for that would be the architecture of shared memory. Shared memory / single instance middleware has its advantages and disadvantages. Anyway, the point is that you don't not need pipes if the memory is shared. I.e. pipes and daemon are mutually exclusive. > I am also going to control instruments over Ethernet anyways so would > investing time in socket programming solve two problems by making it a > socket based server? Once the socket is set up by the daemon, the smaller > "satellite" commands would not need as much overhead to connect to a port > as they would to create a file handler, would they? But instruments do not run middleware. The middleware has two interfaces. The interface for applications and the interface for end devices. Instruments of same type are handled by a middleware device driver/interface designed for them. Distribution layer should consider TCP/IP- or pipes-based protocols as a mere device. > Lastly, this will be done in Ada where ever possible, is there an Ada > oriented way to do this sort of thing? I designed process automation middleware both in C++ and Ada 2005. Ada offers many possibilities, e.g tasking which significantly changes the way of implementing middleware services. It may also mean more work on the architecture, because you have to weigh multitude of possible solutions. There are also many difficulties, e.g. lack of full MI sometimes extremely complicates middleware design, worse, it cripples the API. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de