[llvm] r208007 - [Support/MemoryBuffer] Introduce a boolean parameter (false by default) 'IsVolatile' for the open file functions.

Argyrios Kyrtzidis akyrtzi at gmail.com
Mon May 5 16:58:12 PDT 2014

On May 5, 2014, at 4:54 PM, Alp Toker <alp at nuanti.com> wrote:

> On 06/05/2014 00:43, Argyrios Kyrtzidis wrote:
>> On May 5, 2014, at 4:21 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
>>>> -  if (shouldUseMmap(FD, FileSize, MapSize, Offset, RequiresNullTerminator,
>>>> +  if (!IsVolatile &&
>>>> +      shouldUseMmap(FD, FileSize, MapSize, Offset, RequiresNullTerminator,
>>>>                     PageSize)) {
>>> Why not put this in shouldUseMmap itself?
>> Will do that.
>>> A more serious concern is that the semantics are pretty fuzzy. What
>>> exactly does it mean to change often? If we are at risk of reading
>>> modified data by using mmap, how do we guarantee that we don't read
>>> modified data with read? Is the caller required to hold a lock when
>>> doing the call? If so, that should be a comment saying so.
>> The problem is not the data itself, the problem is that mmap may leave the buffer without a null terminator, because the file size changed by the time mmap brings in the last page.
>> Initializing the memory with read/pread has no such issue, the null terminator is guaranteed.
>>> What is the intended use case for this?
>> libclang passes isVolatile = true for user files, because it has to deal with user files constantly getting edited/updated while trying parse them.
> How about teaching the lexer to take input from a RewriteRope stream?
> Trying to reparse interactive sessions from a monolithic buffer feels like a losing game because the common case of a even single character insertion is inherently expensive.

That's a good idea, and something we want to explore in the future.

Note though that lexing is not the bottleneck currently.

> Alp.
>>> Cheers,
>>> Rafael
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> -- 
> http://www.nuanti.com
> the browser experts

More information about the llvm-commits mailing list