Alexei,
Thanks! The patch was applied OK.
So now we have two main issues:
1. We need to detect the kernel at the build time and prevent
breaking the compilation due to lack of epoll kernel API.
2. We need to detect the kernel at the run time and switch on
EpollSelectorProviderImpl.
For (1) I propose to include <linux/version.h> and then:
#if (LINUX_KERNEL_CODE >= KERNEL_VERSION(2, 6, 0))
// do some epoll activity here
#else
printf("Error: epoll facility is not implemented, please rebuild on
newer kernel\n");
#endif
If it sounds right, I will go ahead and make the patch for it.
Thanks,
Aleksey.
On 10/11/07, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> FYI yesterday I've committed Aleksey's patch for HARMONY-4879.
> However, I afraid in spite of the fact that new epoll-based provider
> is disabled by default corresponding native sources simply cannot be
> compiled if kernel's version is less than 2.5.44 because of unresolved
> references to epoll_ctl. According to manual: " epoll(7) is a new API
> introduced in Linux kernel 2.5.44. Its interface should be finalized
> in Linux kernel 2.5.66." Thus, it looks like we should detect kernel
> version during the build time via "uname --kernel-release" or
> something like it. Did I miss something?
>
> Thanks,
> Alexei
>
> 2007/10/11, Tim Ellison <[EMAIL PROTECTED]>:
> > Apologies for the late response ... still catching up.
> >
> > Aleksey Shipilev wrote:
> > > Hi, Paulex,
> > >
> > >> Amazing work, Aleksey!
> > > Thanks, I was waiting for it :)
> > >
> > >> Seems RI[1] is adapative here, i.e., use epoll when 2.6 kernel is
> > >> detected,
> > >> is it possible for Harmony to implement in similar way? Of course this
> > >> can
> > >> be further work and doesn't necessary to prevent this patch to be
> > >> applied.
> > > I believe it could be done in launcher which could detect the kernel
> > > where Harmony starts and then instantiate right SelectorProvider. I
> > > don't know the details for Harmony launcher though, it's just the
> > > guess. This is in some way contrary with portlib implementation - we
> > > could even implement optimized versions for Selector for Windows and
> > > Linux separately.
> >
> > The launcher would not be the right place to detect the kernel version,
> > since we would want this to work in all places that the NIO code is
> > used, even when people are not using our launcher.
> >
> > Regards,
> > Tim
>
