-----Original Message-----
From: David Oswald
Rob: I notice there are numerous places in the Inline distribution where
we're opening for output but not flocking. I didn't even look at possible
issues where we might be opening for input, reading, then opening for
output and expecting to not tromp on another process that may have gotten
in the middle of the cycle.
The key thing for me is that this absence of flocking has never (afaik) been
reported as an issue for any *user*.
Not wishing to denigrate cpan-testers (who do a fantastic job), but I've
always been loathe to address something that exists only in a smoking
set-up, for fear it's going to open up a can of worms for those who actually
want to make use of the module.
I still see the occasional cpan-tester FAIL report where 'use diagnostics;'
is a fatal error ... which only reinforces my resolve to be a little bit
cautious about the significance of the failures that the cpan-testers throw
up :-)
I think that Inline probably should be
implementing flocking on all outputs, and anytime an output follows a
read, we should use a flocked semaphore file to maintain the lock across
the read/write cycle.
I can't see that this should be necessary except perhaps for the
configuration file that gets written in the top level build directory.
I don't insist on not implementing stuff that's pointless (as along as it
comes at little cost), but I'm a bit wary of *flocking* across the board
because I can never get the damn thing to work *portably* && *silently*.
(Maybe that's just because I'm inexperienced in the use of flock.)
If we do flock, I'd rather do it only where it's proven to be necessary.
I can confirm that even after fixing Inline::CPP,
we still have race conditions that must be coming from inside of Inline,
that rear their ugly head while executing tests in parallel.
Can you give me an actual "use" case - one that's outside the
cpan-tester/smoker/Test::Harness environment ?
That would probably encourage me to become a more responsible and caring
Inline maintainer :-)
The fixes
within Inline shouldn't be too difficult, but there are so many places
that Inline interacts with files, it will be hard to assure we've gotten
all of them.
My thinking is that we can't be missing too much or we would've received at
least one bug report about it from a user in the last 15 years.
I suppose I could implement a semaphore flock at the
beginning of compilation phase for Inline::CPP and release it after
compilation phase finishes. That would make Inline::CPP concurrency-safe
even if Inline were to remain not concurrency-safe. But that's just
sweeping the dust under the carpet. :)
Well ... that'd be good enough for me. Does that work ?
Although (as is clearly evident) I'm not all that passionate about this at
the moment, I would probably find it hard to ignore any patch that:
a) broke none of the current tests;
&&
b) created no noise.
(But I'd still prefer that we flocked only where it's demonstrably needed.)
And I still can't help feeling that cpan-testers/Test::Harness/smokers might
be assuming something of Inline that it was never designed (or intended) to
deliver ... dunno ... again, an actual "use" case demonstrating the problem
would be helpful here.
As you can see, David, I don't entirely agree with your POV at the moment.
But I *do* appreciate that you took the time and effort to express it. (And
I thank you for doing that !!)
Cheers,
Rob
