stack path tries to acquire lock

[thomasvnoort]

Our build environment uses stack path to figure out where to get the binaries to archive. Right now this causes builds to be slow since this step waits for other stack instances in concurrent build jobs to release their lock.

I'd expect stack path to not require any locking at all since it just prints some path information, but I might be overlooking something here.

[chrisdone]

Is that on master?

[thomasvnoort]

Sorry, forgot to mention a version. But yes, this happens both with the 0.1.3.1 release and master.

[snoyberg]

@rrnewton any thoughts on the locking issue here?

[rrnewton]

Sure, if it doesn't side effect the snapshot it should be another exception. I was conservative about locking things.

I'm pretty busy here at ICFP this week, and then PPoPP next week, but if it's not urgent I can get to these little fixes after next week.

[snoyberg]

This should be much less of a problem now that locking is disabled by default, closing.

[thomasvnoort]

I'm a bit confused here, isn't locking required to stay safe when running multiple instances of stack? If so, this issue remains an issue for us and our build environment.

[snoyberg]

Not that I'm aware of, see: #950 (comment)

In any event, stack path definitely is safe without locking.

[thomasvnoort]

Thanks for clarifying, we'll see how this works out in practice :)

[rrnewton]

Hi @thomasvnoort,

I wrote a tiny patch that includes stack path in the opt-out-of-locking exceptions, together with the original set of non-locking commands, which are enumerated in the pull request here.

I made a pull request (#1112) with the patch.