From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1458 invoked from network); 26 Mar 2005 18:12:03 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 26 Mar 2005 18:12:03 -0000 Received: (qmail 57219 invoked from network); 26 Mar 2005 18:11:55 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 26 Mar 2005 18:11:55 -0000 Received: (qmail 20758 invoked by alias); 26 Mar 2005 18:11:46 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8633 Received: (qmail 20744 invoked from network); 26 Mar 2005 18:11:45 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 26 Mar 2005 18:11:44 -0000 Received: (qmail 56206 invoked from network); 26 Mar 2005 18:11:44 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 26 Mar 2005 18:11:40 -0000 Received: from candle.brasslantern.com ([4.11.1.68]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDZ00JL517C4DM0@vms044.mailsrvcs.net> for zsh-users@sunsite.dk; Sat, 26 Mar 2005 12:11:39 -0600 (CST) Received: from candle.brasslantern.com (IDENT:schaefer@localhost [127.0.0.1]) by candle.brasslantern.com (8.12.11/8.12.11) with ESMTP id j2QIBavu019707; Sat, 26 Mar 2005 10:11:36 -0800 Received: (from schaefer@localhost) by candle.brasslantern.com (8.12.11/8.12.11/Submit) id j2QIBZIp019706; Sat, 26 Mar 2005 10:11:35 -0800 Date: Sat, 26 Mar 2005 18:11:35 +0000 From: Bart Schaefer Subject: Re: Opinion: locks, nonblock In-reply-to: To: Felipe Kellermann , zsh-users@sunsite.dk Message-id: <1050326181135.ZM19705@candle.brasslantern.com> MIME-version: 1.0 X-Mailer: Z-Mail (5.0.0 30July97) Content-type: text/plain; charset=us-ascii References: Comments: In reply to Felipe Kellermann "Opinion: locks, nonblock" (Mar 24, 9:18pm) X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On Mar 24, 9:18pm, Felipe Kellermann wrote: } } The [bash] patch adds to options: exlock and nonblock. } That was just a test. exlock implements a lock to every file opened } by the shell (using exec) and nonblock makes O_NONBLOCK'ed operations } (including the possibly exlock'ed I/O). This strikes me as entirely the wrong way to go about this. It's not too horrible for the locking part -- except see below -- but there is a pervasive assumption of blocking I/O in the pipes and redirections model that is basic to the semantics of shell constructs. Non-blocking I/O should be something that's activated in a specific and very narrow context, not turned on and off globally. } For instance, I have been using lockfile (of procmail) to lock files for } years. Now I'm wondering if it would not be nicer to have that operation } natively in my zsh environment. Have you looked at the source for lockfile? It goes to considerable lengths to employ a locking strategy that is safe across networked file systems and a variety of operating system or C library locking protocols, some of which depend on having the name of a file (not the file being locked, an additional file) as a semaphore. A simple flock() as in your patch is not sufficient in a number of cases -- and I won't even go into the maillock(3X) protocol, which is required on a lot more systems than document it, though the shell probably wouldn't be locking email delivery boxes all that often. } Does anyone implemented something like that already? Or else, does } anyone have specific tricks to achieve similar functionality? I've } researched a bit and found nothing. For non-blocking read, look at the zsh/zselect and zsh/system modules. If you use zselect to determine which FDs are ready for reading and then call sysread or syswrite to do the I/O, you can get the effect of a non- blocking read without having to set the descriptor mode. Non-blocking write is trickier. See also the "read" builtin with the -t and -k options. } Do you guys think it would be nice to have that functionality } implemented natively in the shell? It might be useful to add a command to the zsh/system module to perform fcntl() operations. (Note, however, that's incompatible with flock().) I can't decide on the best way to enumerate the possible commands, nor on the right way to return information -- probably something like the format used by the zsh/stat module would be appropriate.