From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26514 invoked by alias); 19 Feb 2017 05:02:29 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 40577 Received: (qmail 10181 invoked from network); 19 Feb 2017 05:02:29 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(0.5/5.0):. Processed in 1.0497 secs); 19 Feb 2017 05:02:29 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=gU4i=2A=brasslantern.com=schaefer@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at bounces.park01.gkg.net does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=3nLpMiKRGKOK+9+4hxCplK3tf3tI61MOxhpsAJpvgkg=; b=1au2IEEuh8VoQsndDkSW1mMXSHNW+arY6EcKZs6EzH2pAOU0fPGCoo6osyOQHI8mrT k4t7/IVZlkzHK25gKHRs9xyHeb1kBuyrXALMzb+gQtj5Lw8iKkEcxX5Gc1iyh3nlQwmO gyInxP6G7E8D2LHel6a4JrjIQ5xZFGvnuGZPOBv2i8fFc+IbjT6Gz8yXm5BuPvG8OzKe aDwuWt8lw4r2XmxV4HdswDdKMeKSKb4PWtV4nQ61akWf+8wdgYjyN5//WO8e96hdt86X rSUxx3uGBpiB7T+1mjgnO74YI0/6cMZS20ZCRGcPhP/92t7i7cjrE59KfSrQJZiAlQNO 4gBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=3nLpMiKRGKOK+9+4hxCplK3tf3tI61MOxhpsAJpvgkg=; b=E9pK53MvOCrR2l4cgP/kexjF1xR1sop59y1q26ArQ389gpwoDUWp0Mo+839wiiJDl9 534F7M4O1zvUTvs5Eb+e++Ki8mcVKKYyqDpIqEZY9htvWgdNI1B397X96JmL8pHmAVly SrUnhnuoL+sTSa5tR3Pjhhg40tXA804fvvyhr10XbLSpWtYPO/plJR8obL9BBDBEjgFL U00mrIEh0weQmtcJLZAHN5nI8sZ5FxDTqbxzowuADhguzW09zNNGzZb7K1ESXN4yVEux z0trBSt5wgNnMzg/cJlmI4lm7Lxb15dCcEC5i/AQWj30+Q/Oricno/XOSThriyBVHGpM Ehaw== X-Gm-Message-State: AMke39nSKY9xgFXW+hvtq/myQBmSuTUzaNkB32jM2J8q6nGXbRiV18UHXfdEpd7pzeu99g== X-Received: by 10.31.82.65 with SMTP id g62mr1437449vkb.150.1487480520195; Sat, 18 Feb 2017 21:02:00 -0800 (PST) From: Bart Schaefer Message-Id: <170218210200.ZM27007@torch.brasslantern.com> Date: Sat, 18 Feb 2017 21:02:00 -0800 In-Reply-To: <1487421943.63900.885130720.703DA037@webmail.messagingengine.com> Comments: In reply to Sebastian Gniazdowski "Closing descriptors in forked (pipe) command" (Feb 18, 4:45am) References: <1487421943.63900.885130720.703DA037@webmail.messagingengine.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Sebastian Gniazdowski , zsh-workers@zsh.org Subject: Re: Closing descriptors in forked (pipe) command MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 18, 4:45am, Sebastian Gniazdowski wrote: } } in db/gdbm module, I do: } addmodulefd(gdbm_fdesc(dbf), FDT_MODULE); } } The point is: forked process inherits database connection. GDBM cannot } have multiple writers (open is in write mode). That's not true -- "man gdbm" even mentions: If the database was opened with the GDBM_NOLOCK flag, the user may wish to perform their own file locking on the database file in order to prevent multiple writers operating on the same file simultaneously. } Maybe it would be good to solve this? FDT_FORKCLOSE or something, there } is closeallelse(), for multiio, didn't go deeper in this. In the general case a subshell should be inheriting all descriptors from the parent, and it's up to the shell programmer not to do stupid things. Consider the case where the parent shell wishes to ztie to the database, fork off a subshell that will make use of the tied parameter, and then go on to exec something else or otherwise exit, leaving the subshell to manage the database. You/we certainly may wish to document that it is dangerous to assume that parent and subshell can both manipulate the tied parameter, but it would be incorrect to automatically close the file descriptor in either of them. This is actually part of the reason why bin_ztie() uses GDBM_SYNC when opening the database file.