Opened 3 years ago

Last modified 11 months ago

#13452 new bug

Lock .tix file

Reported by: dfeuer Owned by:
Priority: normal Milestone:
Component: Code Coverage Version: 8.0.1
Keywords: newcomer Cc: dfeuer
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The HPC documentation warns that

HPC does not attempt to lock the .tix file, so multiple concurrently running binaries in the same directory will exhibit a race condition.

This sounds like something that shouldn't be too terribly hard to fix, once we determine exactly how we want to deal with contention.

Change History (6)

comment:1 Changed 23 months ago by bgamari


This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:2 Changed 21 months ago by bgamari

Keywords: newcomer added
Milestone: 8.6.1

Removing milestone as no one has stepped up to carry this out.

Do ping if this sounds like the sort of project you would be interested in trying.

comment:3 Changed 18 months ago by qrilka

Hi, any advice how this one could be attacked? As I understand file locking isn't a trivial thing to do in a cross-platform way

comment:4 Changed 18 months ago by bgamari

Indeed file locking is non-trivial, as our experiences with #13194 has taught us. If HPC records were written by Haskell code then we could simply piggy-back on the file locking interfaces in base. However, this isn't the case; tix files are written by the RTS. One option would be to change this, implementing the tix I/O bits in Haskell. Another would be to introduce file locking logic into the RTS.

Regardless of how the locking itself will be implemented, the real question is how contention will be dealt with without either losing samples from one of the processes or causing one of the processes to block. It seems to me like this will likely require some refactoring of how TIX samples are read/accumulated/written; IIRC they are currently read by the RTS during startup, accumulated as the program runs, and written during shutdown.

comment:5 Changed 11 months ago by ramirez7

A related question: If I have multiple Haskell green threads (in the same process) in my tests, are the updates to the tix files thread-safe? I couldn't find any statement on the matter in the documentation.

comment:6 Changed 11 months ago by bgamari

I believe multiple Haskell threads should be dealt with properly in the current implementation. If not this would certainly be a bug.

Note: See TracTickets for help on using tickets.