Re: Inline::CPP v0.44: Implement flocking

-----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