[cfe-dev] A few questions about ASTUnit's use of temporary files

[Zachary Turner]

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.


On Fri, Jun 20, 2014 at 1:57 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com>
wrote:

>
> On Jun 19, 2014, at 5:08 PM, Zachary Turner <zturner at google.com> wrote:
>
> 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 ?
>
>   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?
>
>
> On Thu, Jun 19, 2014 at 5:02 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> 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.
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140620/1d598fe4/attachment.html>