[Gluster-devel] Reg. multi thread epoll NetBSD failures

[Shyam]

On 01/23/2015 03:12 PM, Emmanuel Dreyfus wrote:
> Shyam <srangana at redhat.com> wrote:
>
>> Patch: http://review.gluster.org/#/c/3842/
>>
>> Manu,
>>
>> I was not able to find the NetBSD job mentioned in the last review
>> comment provided by you, pointers to that would help.
>
> Yes, sorry, both regression tests hang and I had to reboot the machine,
> hence you do not have the reports in gerrit:
>
> http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/731
> http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/741
>
> Since I got the same horrible result, I did not try retriggering one
> more time, feel free to try it if you need to.
>
>> What is the support status of epoll on NetBSD? I though NetBSD favored
>> the kqueue means of event processing over epoll and that epoll was not
>> supported on NetBSD (or *BSD).
>
> No support for epoll on NetBSD. The alternative would indeed be kqueue,
> but not code has been written to support it. glusterfs on NetBSD uses
> plain poll code right now.
>
>> I ask this, as this patch specifically changes the number of epoll
>> threads, as a result, it is possibly having a different affect on
>> NetBSD, which should either be on poll or kqueue (to my understanding).
>
> I have not looked at the reasons right now, but it must be something
> outside of epoll code since NetBSD does not use it.
>

Various tests on Linux constantly exercise the epoll option, and there 
are changes in the socket and poll code in this commit as well. I would 
assume something here causing a problem, unless others have run this 
through a poll mechanism.

Here is what I indent to do,
- Run with epoll disabled (or poll enabled) on my local box, to see if 
any surprises crop up
- Try the same on the regression suites on gerrit (after some of the 
more recent runs are done)

Manu, request you to go through the non-epoll changes in the submitted 
patch to see if something catches your eye?

Shyam