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

[Anand Avati]

Since all of epoll code and its multithreading is under ifdefs, netbsd
should just continue working as single threaded poll unaffected by the
patch. If netbsd kqueue supports single shot event delivery and edge
triggered notification, we could have an equivalent implantation on netbsd
too. Even if kqueue does not support these features, it might well be worth
implementing a single threaded level triggered kqueue based event handler,
and promote netbsd from suffering from sucky vanilla poll.

Thanks

On Fri, Jan 23, 2015, 19:29 Emmanuel Dreyfus <manu at netbsd.org> wrote:

> Ben England <bengland at redhat.com> wrote:
>
> > NetBSD may be useful for exposing race conditions, but it's not clear to
> > me that all of these race conditions would happen in a non-NetBSD
> > environment,
>
> In many times, NetBSD exhibited cases where non specified,
> Linux-specific behaviors were assumed. I recall my very first finding in
> Glusterfs: Linux lets you use a mutex without calling
> pthread_mutex_init() first. That broke on NetBSD, as expected.
>
> Fixing this kind of issues is interesting beyond NetBSD support, since
> you cannot take for granted that an unspecified behavior will not be
> altered in the future.
>
> That said, I am fine if you let NetBSD run without fixing the underlying
> issue, but you have been warned :-)
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu at netbsd.org
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150124/1dd682bb/attachment.html>