* file.c (realpath_rec): fallback to symlink path when it is
accessible but the link target is not actual entry on file
systems. [ruby-dev:50487] [Bug #14557]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62607 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_stat): File.stat does not accept an IO
object as trying conversion to path name string first. skip
conversion to IO and try stat(2) only.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62606 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Needlessly exporting can reduce performance locally and increase
binary size.
Increasing the footprint of our C-API larger is also detrimental
to our development as it encourages tighter coupling with our
internals; making it harder for us to preserve compatibility.
If some parts of the core codebase needs access to globals,
internal.h should be used instead of anything in include/ruby/*.
"Urabe, Shyouhei" <shyouhei@ruby-lang.org> wrote:
> On Thu, Jan 18, 2018 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > shyouhei@ruby-lang.org wrote:
> >> https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revision&revision=61908
> >>
> >> export rb_mFConst
> >
> > Why are we exporting all these and making the public C-API bigger?
> > If anything, we should make these static. Thanks.
>
> No concrete reason, except they have already been externed in 2.5.
> These variables had lacked declarations so far, which resulted in their
> visibility to be that of extern. The commit is just confirming the status quo.
>
> I'm not against to turn them into static.
This reverts changes from r61910, r61909, r61908, r61907, and r61906.
* transcode.c (rb_eUndefinedConversionError): make static
(rb_eInvalidByteSequenceError): ditto
(rb_eConverterNotFoundError): ditto
* process.c (rb_mProcGID, rb_mProcUid, rb_mProcID_Syscall): ditto
* file.c (rb_mFConst): ditto
* error.c (rb_mWarning, rb_cWarningBuffer): ditto
* enumerator.c (rb_cLazy): ditto
[Misc #14381]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62029 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
POSIX only defines mode_t to be "an integer typea", and in fact
MacOS defines it to be uint16_t. We didn't have NUM2USHORT before
so it did not make sense but now that we have it. Why not check
apptopriately.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61950 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Support nanosec file timestamp on Windows 8 or later.
Original patches are written by kubo (Kubo Takehiro).
Windows 7 and earlier also supports nanosec file timestamp, but it's too
accurate than system time. so, this feature is disabled on such versions.
[Feature #13726]
this change also includes [Misc #13702]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61013 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Like stat(2), the access(2) syscall may take an indeterminate
amount of time on slow/remote filesystems.
This lets the following methods release the GVL to avoid choking
the entire VM while one thread is stuck on a slow or
non-responsive filesystem:
- File.readable?
- File.readable_real?
- File.writable?
- File.writable_real?
- File.executable?
- File.executable_real?
* file.c (nogvl_eaccess): new function
(nogvl_access): ditto
(rb_access): new wrapper function
(rb_eaccess): release GVL
(rb_file_readable_real_p): use rb_access
(rb_file_writable_real_p): ditto
(rb_file_executable_real_p): ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60925 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This will make future work to release GVL here simpler.
* file.c (rb_eaccess): new function
(rb_file_readable_p): use rb_eaccess
(rb_file_writable_p): ditto
(rb_file_executable_p): ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60895 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
mkfifo(3) is subject to the same problems as open(2) on slow
filesystems. Release the GVL and let the rest of the VM run
while we call mkfifo.
* file.c (nogvl_mkfifo): new function
(rb_file_s_mkfifo): release GVL
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60861 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
mode_t is the correct type for mkfifo(3). This fixes an
oversight from r60592 which made the same change to several
other functions.
* file.c (rb_file_s_mkfifo): use mode_t instead of int
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60847 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (nogvl_truncate): cast int to VALUE before "void *"
(rb_file_s_truncate): cast "void *" to VALUE before int
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60846 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The `readlink' can stall on slow filesystems like `open' and
`read' syscalls. Release the GVL and let the rest of the VM
function while `readlink' runs.
* file.c (nogvl_readlink): new function
(readlink_without_gvl): ditto
(rb_readlink): use readlink_without_gvl
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60845 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Like IO#write and IO.open, these file operations have
unpredictable performance on slow file systems. Allow other
threads of the VM to proceed while they are taking place.
* file.c (nogvl_truncate): extract from rb_file_s_truncate
(rb_file_s_truncate): release GVL
(nogvl_ftruncate): extract from rb_file_truncate
(rb_file_truncate): release GVL
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60844 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c: [DOC] fix grammar in docs for File#path
and use a stronger description than "inaccurate".
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60706 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_check_realpath_internal): infetct the result with
arguments, no taint if none are tainted and cwd is not used.
[ruby-core:83583] [Bug #14060]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60599 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_check_realpath_internal): infetct the result with
arguments, no taint if none are tainted and cwd is not used.
[ruby-core:83583] [Bug #14060]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60596 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
mode_t is the correct type for these syscalls and it can be
easier-to-understand. It may also help portability to future
platforms and improve type checking.
* dir.c (dir_s_mkdir): use mode_t for mkdir(2)
* file.c (chmod_internal): use mode_t for chmod(2)
(rb_file_s_chmod): s/int/mode_t/
(lchmod_internal): ditto, deref pointer as in chmod_internal
(rb_file_s_lchmod): pass pointer as in rb_file_s_chmod
(rb_file_s_rename): use mode_t for umask(2)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60592 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This means File.chmod, File.lchmod, File.chown, File.lchown,
File.unlink, and File.utime operations on slow filesystems
no longer hold up other threads.
The platform-specific utime_failed changes is compile-tested
using a new UTIME_EINVAL macro
This hurts performance on fast filesystem, but these methods
are unlikely to be performance bottlenecks and (IMHO) avoiding
pathological slowdowns and stalls are more important.
benchmark results:
minimum results in each 3 measurements.
Execution time (sec)
name trunk built
file_chmod 0.591 0.801
Speedup ratio: compare with the result of `trunk' (greater is better)
name built
file_chmod 0.737
* file.c (UTIME_EINVAL): new macro to ease compile-testing
* file.c (struct apply_arg): new struct
* file.c (no_gvl_apply2files): new function
* file.c (apply2files): release GVL
* file.c (chmod_internal): adjust for apply2files changes
* file.c (lchmod_internal): ditto
* file.c (chown_internal): ditto
* file.c (lchown_internal): ditto
* file.c (utime_failed): ditto
* file.c (utime_internal): ditto
* file.c (unlink_internal): ditto
[ruby-core:83200] [Feature #13996]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60386 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Because NaCl and PNaCl are already sunset status.
see https://bugs.chromium.org/p/chromium/issues/detail?id=239656#c160
configure.ac: Patch for this file was provided by @nobu.
[Feature #14041][ruby-core:83497][fix GH-1726]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60374 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (file_alt_separator): define only on DOSISH platforms.
File::ALT_SEPARATOR is nil on cygwin.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60159 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Like stat(2), lstat(2) can be expensive on slow filesystems and
should not block other threads. There should be a minor, but
not significant slowdowns in single-threaded performance similar
to benchmarks around the more-portable stat(2):
[ruby-core:83012] [Bug #13941]
* file.c (no_gvl_lstat): new function for rb_thread_call_without_gvl
(lstat_without_gvl): new wrapper to replace lstat(2) calls
(rb_file_s_lstat): s/lstat/&_without_gvl/
(rb_file_lstat): ditto
(rb_file_symlink_p): ditto
(rb_file_s_ftype): ditto
(rb_file_expand_path_internal): ditto
(realpath_rec): ditto
[ruby-core:83075] [Feature #13963]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60110 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_rename): `struct rename_args ra` already has members
which contain C ptrs. Pointed by MSP-Greg. Thanks!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60093 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_rename): src and dst are used only on DOSISH env.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60092 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rename(2) requires two pathname resolution operations which can
take considerable time on slow filesystems, release the GVL so
operations on other threads may proceed.
On fast, local filesystems, this change results in some slowdown
as shown by the new benchmark. I consider the performance trade
off acceptable as cases are avoided.
benchmark results:
minimum results in each 3 measurements.
Execution time (sec)
name trunk built
file_rename 2.648 2.804
Speedup ratio: compare with the result of `trunk' (greater is better)
name built
file_rename 0.944
* file.c (no_gvl_rename): new function
(rb_file_s_rename): release GVL for renames
* benchmark/bm_file_rename.rb: new benchmark
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60088 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
For apply2files, all callers use the `path' VALUE for
generating exceptions, so there is no need to guard it.
In realpath_rec, RB_GC_GUARD is already used on link_orig.
In rb_check_realpath_internal, RB_GC_GUARD is necessary and
preferable (see Appendix E. of doc/extension.rdoc)
* file.c (apply2files): remove unnecessary volatile
(realpath_rec): ditto
(rb_check_realpath_internal): ditto, and add RB_GC_GUARD
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60081 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
At the moment rb_stat function is blocking. This patch changes the
behaviour to release the gvl while waiting for OS to return from
f(stat).
There is behaviour impact, but not significant (times are for 100000
iterations):
$ ~/releaseruby_patch/bin/ruby bench.rb
Rehearsal ------------------------------------------------
File.exist?: 0.036412 0.056616 0.093028 ( 0.093075)
--------------------------------------- total: 0.093028sec
user system total real
File.exist?: 0.042953 0.049783 0.092736 ( 0.092804)
$ ~/releaseruby_no_patch/bin/ruby bench.rb
Rehearsal ------------------------------------------------
File.exist?: 0.056094 0.026293 0.082387 ( 0.082389)
--------------------------------------- total: 0.082387sec
user system total real
File.exist?: 0.037250 0.046702 0.083952 ( 0.083956)
Based on the patch by Wolf <wolf@wolfsden.cz> at [ruby-core:83012],
with using `rb_thread_io_blocking_region` for `fstat`.
[Bug #13941]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60027 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_check_realpath): returns real path which has no
symbolic links. similar to rb_realpath except for returning
Qnil if any parts did not exist.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59983 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_basename, rb_file_s_dirname): [DOC] state
that trailing separators will be stripped first, like as
basename(1) and dirname(1). [ruby-core:82828] [Bug #13908]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59933 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
File#path for a file opened with O_TMPFILE has no meaning.
A filepath returned by this method isn't guarranteed about its accuracy,
but files opened with O_TMPFILE are known its recorded path has no
meaning. So let them not to return any pathname.
After a discussion in ruby-core, just returning Qnil makes guessing the
root cause difficult. Instead, this patch makes the method to raise an
error.
Other consideration is calling fnctl(2) on rb_file_path, but it adds a
overhead, and it's difficult to determine O_TMPFILE status after fd has
been closed.
[Feature #13568]
* io.c(rb_file_open_generic): Set Qnil to fptr->pathv when opening a
file using O_TMPFILE
* file.c(rb_file_path): Raise IOError when fptr->pathv is Qnil
* file.c(rb_file_path): [DOC] Update for the new behavior
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59704 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (rb_file_s_mkfifo): enclose rdoc by ifdef so it will be
generated properly.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59443 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* dir.c (rb_dir_getwd_ospath): return cwd path in the OS path
encoding.
* file.c (rb_realpath_internal): work in the OS path encoding
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59040 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* file.c (path_check_0): preserve encoding of path name in warning
message.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59008 b2dd03c8-39d4-4d8f-98ff-823fe69b080e