A few questions about ASTUnit's use of temporary files

Question for the wider list: Can someone explain ASTUnit’s use temporary files? Do we only ever open the files once and then that’s it? Or is there a chance of passing the filename around to someone else, who will then try to open it again? Are these normal temporary files, in the sense that they’re expected to be always closed on process exit?

Question for Argyrios: I’m looking at a fairly old revision you submitted, r159664. The commit message here is as follows:

[libclang] Protect against a race condition where a thread
may be destroying an ASTUnit while cleanupOnDiskMapAtExit is
getting called.

rdar://11781241

Unfortunately I can’t see this rdar link, so I don’t have any more context. Can you elaborate on this race condition? My guess is that we’re running multiple threads, someone calls ::exit(), and then the running threads race against this atexit handler.

I’d like to fix this “properly”, but it’s difficult without have more context about this race.

Actually, upon closer inspection, nobody even adds any temporary files to this. Ever. Is this used for some kind of out-of-tree support? If so, it seems reasonable to require that anyone who wants this implement this in their own code. Maybe clang shouldn’t even have this.

Does anyone depend on this functionality and object to me deleting it?

Actually, upon closer inspection, nobody even adds any temporary files to this. Ever.

ASTUnit::addTemporaryFile doesn’t seem that is getting used, but ASTUnit itself calls ‘setPreambleFile()’ which registers the precompiled preamble file with OnDiskData to be removed.

What are you trying to fix ?

As part of a larger effort to replace LLVM’s mutexes with std::mutex / std::recursive_mutex (which might end up being stalled for other reasons, but let’s just assume it will move forward for the purposes of this discussion), I found that MSVC’s implementation of std mutexes cannot be run during an atexit handler. They simply don’t work. This led to a deadlock in this function when I used a std mutex.

At a higher level, it seems fundamentally wrong to even be trying to acquire a mutex during thread shutdown anyway, so I was trying to remove this mutex entirely. I suspect it happens because someone calls exit() (maybe indirectly through a call to report_fatal_error) while multiple threads were running.

If it’s only the preamble file, maybe it’s possible to remove this file without acquiring a mutex.