From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: MAIL_USE_FLOCK and Debian. Date: Tue, 18 Feb 2003 10:03:32 -0600 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <874r717ezv.fsf@raven.i.defaultvalue.org> References: <87lm0ijabw.fsf@raven.i.defaultvalue.org> <87znoxi93a.fsf@raven.i.defaultvalue.org> <87ptpqhqjp.fsf@raven.i.defaultvalue.org> <874r7238p9.fsf@deneb.enyo.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045584426 7165 80.91.224.249 (18 Feb 2003 16:07:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Feb 2003 16:07:06 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18lAGs-0001rG-00 for ; Tue, 18 Feb 2003 17:07:02 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18lAVp-0007ym-00 for ; Tue, 18 Feb 2003 17:22:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18lAJ9-000089-03 for emacs-devel@quimby.gnus.org; Tue, 18 Feb 2003 11:09:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18lAIZ-0008Q2-00 for emacs-devel@gnu.org; Tue, 18 Feb 2003 11:08:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18lAGS-00079I-00 for emacs-devel@gnu.org; Tue, 18 Feb 2003 11:06:37 -0500 Original-Received: from dsl093-098-016.wdc1.dsl.speakeasy.net ([66.93.98.16] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18lADV-0005mX-00; Tue, 18 Feb 2003 11:03:33 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id AA13361C; Tue, 18 Feb 2003 10:03:32 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id CBAABC9FC9; Tue, 18 Feb 2003 10:03:32 -0600 (CST) Original-To: Florian Weimer In-Reply-To: <874r7238p9.fsf@deneb.enyo.de> (Florian Weimer's message of "Mon, 17 Feb 2003 22:20:50 +0100") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Original-cc: rms@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11736 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11736 Florian Weimer writes: > Maybe Emacs can offer access to the relevant system calls, so > movemail can be implemented in Lisp? It can't be *that* hard... Oh, and although it looks like it's not going to matter, you're definitely right about being able to implement movemail in Lisp if we wanted to. As an example, you might be able to implement the Debian strategy (embodied in liblockfile) right now, without any changes to Emacs, since it uses fairly unremarkable system calls. From lockfile_create(3): The algorithm that is used to create a lockfile in an atomic way, even over NFS, is as follows: 1 A unique file is created. In printf format, the name of the file is .lk%05d%x%s. The first argument (%05d) is the current process id. The second argument (%x) consists of the 4 minor bits of the value returned by time(2). The last argument is the system host- name. 2 Then the lockfile is created using link(2). The return value of link is ignored. 3 Now the lockfile is stat()ed. If the stat fails, we go to step 6. 4 The stat value of the lockfile is compared with that of the tem- porary file. If they are the same, we have the lock. The tempo- rary file is deleted and a value of 0 (success) is returned to the caller. 5 A check is made to see if the existing lockfile is a valid one. If it isn't valid, the stale lockfile is deleted. 6 Before retrying, we sleep for n seconds. n is initially 5 sec- onds, but after every retry 5 extra seconds is added up to a maximum of 60 seconds (an incremental backoff). Then we go to step 2 up to retries times. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4