[Bug 1586295] Review Request: rubygem-bootsnap - Boot large ruby/ rails apps faster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1586295



--- Comment #8 from Jun Aruga <jaruga@xxxxxxxxxx> ---

> I do not think wee need to do anything with the `call-to-mktemp` - see below.
> 
> Reading the code:
>  * On C level [1] - expects atomic access to a file (used for caching only, reasonable hashing method is used); and
>  * On Ruby level [2] - Mutex is used for synchronizing the Threads

Are you sure?
It seems that the method "atomic_write_cache_file" which mktemp is called in is
expecting as a attomic.
But seeing the actual logic, I think the logic [2] is not related to the called
method atomic_write_cache_file. As you know, Mutex itself is used for native
thread. But it does not guarantee atomic access if lock is not used. It depends
on the implementation.

lib/bootsnap.rb Bootsnap::CompileCache.setup
-> lib/bootsnap/compile_cache.rb Bootsnap::CompileCache.setup.
  -> lib/bootsnap/compile_cache/iseq.rb: Bootsnap::CompileCache::Native.fetch
def self.install!(cache_dir)
  -> lib/bootsnap/compile_cache/yaml.rb: Bootsnap::CompileCache::Native.fetch
def self.install!(cache_dir)
    -> ext/bootsnap/bootsnap.c
      rb_define_module_function(rb_mBootsnap_CompileCache_Native, "fetch",
bs_rb_fetch, 3);
      bs_rb_fetch -> bs_fetch -> 
      atomic_write_cache_file <= it looks atomic access from the method name.
          tmp_path = mktemp(template);

For example it seems that when below logic is called several times at same
timing, it does not guarantee the atomic access.

```
irb(main):001:0> require 'bootsnap'
irb(main):006:0> Bootsnap.setup(cache_dir: '/tmp/foo', autoload_paths_cache:
false)
=> :load_file
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx/message/3NDF7G4YLCST2LYUYIIJA3BGAG37L7MQ/




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux