From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.140.128.1 with SMTP id a1cs13672rvd; Sun, 7 Mar 2010 16:18:39 -0800 (PST) Received-SPF: pass (google.com: domain of 3XkKUSwwICoArsvqeptivwsr2lfx.rixvego-hizipksskpikvsytw.gsq@groups.bounces.google.com designates 10.142.151.42 as permitted sender) client-ip=10.142.151.42; Authentication-Results: mr.google.com; spf=pass (google.com: domain of 3XkKUSwwICoArsvqeptivwsr2lfx.rixvego-hizipksskpikvsytw.gsq@groups.bounces.google.com designates 10.142.151.42 as permitted sender) smtp.mail=3XkKUSwwICoArsvqeptivwsr2lfx.rixvego-hizipksskpikvsytw.gsq@groups.bounces.google.com; dkim=pass header.i=3XkKUSwwICoArsvqeptivwsr2lfx.rixvego-hizipksskpikvsytw.gsq@groups.bounces.google.com Received: from mr.google.com ([10.142.151.42]) by 10.142.151.42 with SMTP id y42mr750707wfd.22.1268007519311 (num_hops = 1); Sun, 07 Mar 2010 16:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:date:from:to:subject:message-id :references:mime-version:in-reply-to:user-agent :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:sender:list-subscribe:list-unsubscribe :content-type:content-disposition:content-transfer-encoding; bh=RVh2M5VpA/C6eKkDLpomqaKbZ3FagvF4Y77291xQQRg=; b=zFExnJb3kJnc/ksT+8CgsbZbX0z9K+RIH8CKnQuBx6NR1CyxRbEI0aC4A9dxHtgdvv 7zJISu996SEA8Bjpbx2DhaDgtk0ttK8GdnwrN6lHlWvME2WrQ+vbJFsHyGCYYJb/IfO4 kFwNJRQizTDaiLgSCmypNEPd8HzT04oWDLPAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:date:from:to:subject:message-id:references :mime-version:in-reply-to:user-agent :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:sender:list-subscribe:list-unsubscribe :content-type:content-disposition:content-transfer-encoding; b=QHUfgpWfF+ZkRIqnq0ehq3WHhP8zktP1ny6G6bN8MsqUWId1YBbnAVA+7PuzFq0M83 ybe3JdW9DCdE0euggTwEZ0sNfbkCAtXwYXw7g4gi5JXEzw55xPABvUVLYr7btQMYN3xr 6jjIGXaLxP2UI5O5G+GVMKGe6ybUFwMpq+Zz4= Received: by 10.142.151.42 with SMTP id y42mr87152wfd.22.1268007518072; Sun, 07 Mar 2010 16:18:38 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.141.187.19 with SMTP id o19ls840477rvp.0.p; Sun, 07 Mar 2010 16:18:36 -0800 (PST) Received: by 10.141.124.7 with SMTP id b7mr688904rvn.5.1268007516098; Sun, 07 Mar 2010 16:18:36 -0800 (PST) Received: by 10.141.124.7 with SMTP id b7mr688903rvn.5.1268007516072; Sun, 07 Mar 2010 16:18:36 -0800 (PST) Return-Path: Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by gmr-mx.google.com with ESMTP id 40si1224928pxi.1.2010.03.07.16.18.35; Sun, 07 Mar 2010 16:18:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of normalperson@yhbt.net designates 64.71.152.64 as permitted sender) client-ip=64.71.152.64; Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id 59A8C1F73A; Mon, 8 Mar 2010 00:18:35 +0000 (UTC) Date: Sun, 7 Mar 2010 16:18:34 -0800 From: Eric Wong To: rack-devel@googlegroups.com Subject: Re: Not cleaning up tempfiles for multipart? Message-ID: <20100308001834.GA18365@dcvr.yhbt.net> References: <20100306075548.GB6474@dcvr.yhbt.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: best guess record for domain of normalperson@yhbt.net designates 64.71.152.64 as permitted sender) smtp.mail=normalperson@yhbt.net X-Original-Sender: normalperson@yhbt.net Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/6eb2bc7a1f8c072c X-Message-Url: http://groups.google.com/group/rack-devel/msg/a42a6cebeb0572d7 Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Charles Oliver Nutter wrote: > On Sat, Mar 6, 2010 at 1:55 AM, Eric Wong wrote: > > Charles Oliver Nutter wrote: > >> If I'm correct, this is a bug. Tempfiles should not be relied upon to > >> clean themselves up in response to GC, since you don't know when GC > >> will fire... > > > > Why not?  Tempfiles are objects, too.  It's perfectly reasonable > > to let GC clean them up like any other object. > > > > > > I don't know why RewindableInput is monkeying with Tempfile internals, > > though. > > It's roundly considered by every programming language community in the > world to be *really* bad form to let GC clean up IO. There's tons of > reasons for this: You're forgetting there are programming language communities that consider GC to be bad form in the first place :) Given that Ruby does have a GC, I'd prefer to be as lazy as possible and let the runtime deal with it. > * GC may not run as soon as you like, causing you to hold IO resources > too long (and under heavy load, potentially use up all descriptors for > a process) MRI considers EMFILE/ENFILE to be analogous to ENOMEM, and would trigger GC in that case. > * On some systems, old objects get promoted to heaps that are only > rarely collected, resulting in them potentially never GCing (or only > GCing extremely rarely) Those GCs could be made smarter about dealing with IO objects. > * There's no reason you *shouldn't* be able to close resources when > they're no longer used. In this case, close any files opened for a > give request once the request has been processed (async libraries > using those files should expect them to be closed and deal with that > accordingly). Of course being able to close IO objects explicitly is good. In some cases of socket/pipe IPC, it's the _only_ way to signal end-of-input. HTTP/1.0 and HTTP/0.9 don't work otherwise. > Bug-finding tools for several languages flag this sort of behavior as > a high-priority bug. Languages like Go, C#, and Java have or are > adding features to help guarantee you never do this. It's pretty much > universally frowned upon. As I understand it, C# and Java have to deal with operating/file systems that don't work with unlinked files. I guess JRuby is limited to only being able to use things that work on those platforms, and can't work with unlinked temporary files reliably, my condolences. I haven't had a chance to look Go... > When I tweeted about Rubyists leaving IO objects to be cleaned up or > closed by GC, *everyone* agreed that it's a bug in the code, and that > nobody should ever rely on GC to release File/IO resources. > > What more can I say? :) *everyone* meaning your followers on Twitter? I suspect your followers on Twitter are more inclined to agree with you :) -- Eric Wong