From: Vladimir Sizikov <vsizikov@...>
Date: 2010-01-24T19:35:17+09:00
Subject: [ruby-core:27756] Re: [Bug #2619] Proposed method: 	Process.fork_supported?

Hi,

On Sun, Jan 24, 2010 at 5:00 AM, Tanaka Akira <akr@fsij.org> wrote:
> 2010/1/22 Tanaka Akira <akr@fsij.org>:
>
>> FFI cannot test function availability?
>
> It seems attach_function in FFI raises FFI::NotFoundError if the specified
> function is not found.
>
> I don't understand why the detection is not reliable enough.

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.

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.

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.

Less important, but still worth mentioning:

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.

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).

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?.

So, as you see, this whole thing is just a special case on top of
special case on top of another one. Pretty ugly, and still can't be
100% reliable, and is not really fully documented. While the original
behavior was simple and straightforward: iff there is a method
defined, than respond_to? returns true. This is natural approach in
object-oriented environments, no platform or implementation
capabilities should play a role here.

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.

Thanks,
  --Vladimir