Re: g_file_write()

[Soeren Sandmann <sandmann daimi au dk>]

mortenw gnome org (Morten Welinder) writes:

> 1. It is hideously expensive.

This is already a fairly expensive function. And fork() is really not
that bad. My system can fork more than 200000 times per second.  If
you need to write tons of small files quickly, you should (a) not use
this function, and (b) reconsider your design.

> 2. It is quite difficult to get right in a library.
> 
> Consider: you fork, the child does its thing and exits,
> a signal handler you didn't know about waits on the child,
> and you call waitpid.
> 
> If you are lucky, that waitpid just returns an error (ECHILD).
> Your code then accesses "status" which hasn't been set.

Right, I should handle waitpid() error returns. Don't know how I
missed that; probably some thinko like 'it returns the pid, but I
already know that'.

> If you are less lucky (aka the OS and the application programmer
> are out to get you), then the waitpid will hang waiting for another
> process.  You can probably ignore this.

I have no scruples dismissing that as "don't do that, then".

> waitpid can also fail for other reasons.  A signal could cause
> EINTR, for example.
> 
> (And then there is the usual should-have-saved errno comment.
> _() could have changed it.)

Right, thanks. This is also a problem in several other places in the
g_file_replace() functions.

> Why 0666 and not 0777, btw.?  One could conveniently write scripts
> this way.

To emulate what you would get if you just used 

        fopen ("foo", "wb");

It is also what "touch foo" would produce. I think it's reasonable to
expect the application to change the permissions themselves if they
want to generate scripts.

> Tell me again why we want this function to be anything but the
> simple open+write+close?

Because the atomic write behavior is useful in many cases, and not
generally harmful. The fact that it has taken some iterations to get
right is actually an argument in favor of having a glib function for
it.


Søren