From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19565 invoked from network); 17 Jun 2009 00:51:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 17 Jun 2009 00:51:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 46044 invoked from network); 17 Jun 2009 00:51:06 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Jun 2009 00:51:06 -0000 Received: (qmail 7365 invoked by alias); 17 Jun 2009 00:50:35 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14199 Received: (qmail 7352 invoked from network); 17 Jun 2009 00:50:34 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 17 Jun 2009 00:50:34 -0000 Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by bifrost.dotsrc.org (Postfix) with ESMTP id 871278027106 for ; Wed, 17 Jun 2009 02:50:29 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.219.58]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KLC00KFUY7MALD3@vms173009.mailsrvcs.net> for zsh-users@sunsite.dk; Tue, 16 Jun 2009 19:47:54 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n5H0ljnm032729; Tue, 16 Jun 2009 17:47:46 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n5H0ljVG032728; Tue, 16 Jun 2009 17:47:45 -0700 From: Bart Schaefer Message-id: <090616174745.ZM32727@torch.brasslantern.com> Date: Tue, 16 Jun 2009 17:47:45 -0700 In-reply-to: <7c737f300906152017m7776d596he8a1251c9e1279b8@mail.gmail.com> Comments: In reply to Alexy Khrabrov "serverizing a fat process with named pipes" (Jun 15, 11:17pm) References: <7c737f300906152017m7776d596he8a1251c9e1279b8@mail.gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Alexy Khrabrov , zsh-users@sunsite.dk Subject: Re: serverizing a fat process with named pipes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9472/Tue Jun 16 19:24:06 2009 on bifrost X-Virus-Status: Clean On Jun 15, 11:17pm, Alexy Khrabrov wrote: } } I have a heavy process, an English parser loading megabytes of models, } and then reading stdin, sentence per line, outputting the parsed text } to the stdout. How do I properly serverize it -- running in the } background with p2, those created with mkfifo p1 p2? As PWS mentioned in his reply, the nature of FIFOs is that the reader blocks until a writer opens it, and then the reader gets EOF when the writer closes it (and the reader has consumed all the data). If the parser is designed to exit upon EOF, then you can't "serverize" it with FIFOs without repeatedly respawning it. If it does NOT exit on EOF, then something still needs to re-open the FIFO each time, because once the original writer exits the reader will always see EOF on the FIFO. You may be able to work around this as follows: exec {fd}>p1 # Open p1 for writing, but don't write anything cat p2 # Replace "cat" with your server process Now other writers can open p1 and send lines to it and even close it again, but "cat" never sees EOF because the shell is holding open $fd. There are still various buffering issues including making sure that someone is appropriately reading from p2, so you might want to look into using inetd or the equivalent to run the process as a service on a socket with a well-known port number instead.