Re: Not cleaning up tempfiles for multipart?

[James Tucker <jftucker@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]


On 6 Mar 2010, at 10:25, Hongli Lai wrote:

> On Mar 6, 8:55 am, Eric Wong <normalper...@yhbt.net> wrote:
>> Charles Oliver Nutter <head...@headius.com> 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.
> 
> Phusion Passenger terminates worker processes by calling exit!. This
> does not call finalizers on MRI, causing temp files to be left behind
> sometimes.

So use #exit. Speed isn't everything.

> There seems to be no way to call finalizers, even GC.start
> doesn't work. I too would like to see Tempfiles being cleaned up
> explicitly.

GC.start makes no promises of determinism, so expecting it to have any effect is wrong thinking, expecting calls over a longer time period to eventually do something, sure, but immediate, no.

The cleanup will have to be done by the handler stack or a wrapping middleware as Eric has pointed out.

> Other than that, I've seen system administrators who are confused by
> the fact that such Tempfiles are not immediately cleaned up. Some
> people who operate websites that handle a large number of concurrent
> uploads are worried that they might run out of disk space because of
> this.

There's no accounting for sysadmins who can't use lsof.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]