Re: Reg. multi thread epoll NetBSD failures

[Anand Avati <avati@xxxxxxxxxxx>]

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@xxxxxxxxxx> wrote:

Ben England <bengland@xxxxxxxxxx> 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@xxxxxxxxxx
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel