On Wed, Oct 3, 2012 at 01:53:28PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Yes, but those framework libraries are typically supposed to prevent
> > such problems from being seen by applications calling them.
>
> How exactly would a library prevent such problems? In particular,
> let's see a proposal for how libpq might make it look like a fork
> was transparent for an open connection.
I guess that is impossible.
> > This is
> > certainly sloppy practice on Apple's part, and it leave us wondering if
> > we are using anything that might be a problem. The bottom line is that
> > we don't know.
>
> > Libraries are supposed to document these limitations, as we do with
> > libpq. I wonder if they just documented fork() and now don't feel they
> > need to document these limitations per-library.
>
> Do we know that they *didn't* document such issues per-library?
> Mentioning the risk under fork() too doesn't seem unreasonable.
>
> Not trying to sound like an Apple apologist, but I see a whole lot of
> bashing going on here on the basis of darn little evidence.
Well, ideally if Apple is going to brand a Unix function as unsafe, it
would be good to mention which libraries are unsafe. I have no idea if
they are documenting the problems in the libraries themselves.
I guess my point is that the fork() warning was too vague.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
