[ruby-core:27848] Re: [Bug #2619] Proposed method: Process.fork_supported?

2010/1/24 Vladimir Sizikov <[e-mail]>:
>
> 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