On Mon, Oct 11, 1999 at 10:52:56AM +0200, Raphael Quinet <quinet@xxxxxxxxxx> wrote:
> This is fine from within the Gimp. But most of the time I want to
> monitor the size of the swap file from a shell window, while the Gimp
> is performing some memory- and CPU-intensive tasks on a large image.
> If we unlink the file after opening it, then the file may not be
> visible in a directory listing. I suppose that this depends on the OS
> and filesystem used.
But this sounds as if this is debugging code for the developers debugging or
hacking the swap code.
A normal user has nothing to do with the swap file, except that he will
find that his disk is full and many hours later he might even find the
reason....
> So if we have to do this in a signal handler anyway, why would we also
> do it just after opening the file?
Because it works. Doing it in the signal handler doesn't. If the gimp
doesn't crash there is no problem. If it does crash the signal handler
often isn't called at all.
I think it's ok to leave it as is in the developers version. In the
release, however, we should not leave (very large and very hidden!) swap
files around.
> In some cases, you do not have the choice. On several machines that I
> use at work, I have to put the swap file on NFS because all writable
> partitions are mounted over NFS (except for /tmp but it is too small).
unlink also works over nfs.
> Are you sure about that? I think that it is more likely that the Gimp
> crashes and calls the signal handler than to have a power failure
> (which has more serious effects than just leaving a swap file around).
At leats during my owrk gimp either crashes silently or goes into an endless
loop. How do I know a signal handler is called? Also, a segfault is often
non-catchable (in practise, not in theory).
> It could still be possible to use tmpfile() as long as we clear or
> override TMPDIR from inside the Gimp, but this is not a very elegant
> solution.
But a very portable solution. And it also works. However, just doing
remove() after the open and ignoring errors might be good enough (the
win32 port where this is not possible already uses a different method to
make it reliable, or so I understood it).
> I would prefer to have the file closed and unlinked in a signal
> handler. This is not a perfect solution (e.g. in case of power
> failure)
... and crashes.
> but it has more advantages than the other solutions (or at least less
> disadvantages).
Well, I admit people hacking the swap code wouldn't find it funny. But
adding an ifdef for these developers in the source sounds much better than
impairing every unlucky user.
(tmpfile or unlink is the only reliable solution so far)
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
