From: Tanaka Akira Date: 2010-01-26T18:48:05+09:00 Subject: [ruby-core:27848] Re: [Bug #2619] Proposed method: Process.fork_supported? 2010/1/24 Vladimir Sizikov : > > One of the reasons you've mentioned earlier: ENOSYS on POSIX systems > and E_NOTIMPL/ERROR_CALL_NOT_IMPLEMENTED on Windows. So the mere > presence of the method is not a guarantee that it will actually work > on particular system. I think ENOSYS is not a practical problem. The system calls which corresponds to Ruby's methods are well standardized, pretty old system calls. So libc and kernel are tends to consistent and ENONSYS are happen unusually. > Second, MRI behavior treats in such special way only C-level methods, > while all the Ruby-level methods that raise NotImplementedError are > treated differently. So the users of the API need to know this > low-level/implementation detail in order to understand which method > could be checked with respond_to? and which couldn't. I implemented and proposed Module#notimplemented_method to define such methods in Ruby level. It is not accepted yet, though. > Third, libffi itself is not supported on all platforms/architectures > where JRuby runs. For those cases we can't use it. > And, in some cases/environments the use of native support in JRuby is > prohibited and we can't use it. If libffi is not usable, system calls are not callable. So no detection problem. > Also, not all not-implemented features depend on underlying platform, > some are just can't be implemented sanely on JRuby, that's yet another > special case to handle. There is no availability detection problem for methods, such as fork, not implementable in JRuby. They are always not implemented. > JRuby uses jnr-posix 3rd party library (Java Native Runtime - POSIX), > it doesn't provide the capability to check which method is implemented > and which is not. Not to mention that there is a feature to map posix > method names to local platform method names at *runtime*, which > further complicates the matters, since until you call the method, you > don't know which native method will be actually called. And in some > cases one POSIX-like method is implemented via multiple calls on > particular platfrom (specifically, Windows). It seems jnr-posix checks the system call availability internally. http://kenai.com/projects/jnr/sources/posix/show So it should be possible to provide the information to JRuby. > Not to mention that loading FFI (esp. at startup) is costly and we try > to delay it if we can, but with this approach to respond_to? the > method call of respond_to? will cause the loading of FFI. Plus we have > to specialize respond_to? implementations for those classes that could > have "not implemented" methods, this is also not ideal for JVM > performance. And we'd pay some performance penalty for runtime system > capabilities introspection, keeping the lists of "not-implemented" > methods, doing special cases in respond_to?. FFI is anyway required when the system call is actually called. So the performance hit on respond_to? is not a problem if the system call is called after respond_to? is called. Since Ruby methods has several attributes such as visibility, one more attribute for possible not-implemented flag is enough. I remember JRuby people proposed annotation. The flag can be viewed as an annotation for methods. > In those really important cases where is important/critical to > introspect platfrom/API/impl capabilities, there should be a > stand-alone API, and hijacking the base OO instruments for that is not > appropriate, in my opinion. respond_to? is well-known way to test the capability for duck-typing. So programmers needs less learning if we provide the information by respond_to?. -- Tanaka Akira