From owner-freebsd-java@FreeBSD.ORG Sun Jan 31 22:21:53 2010 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B137106566C for ; Sun, 31 Jan 2010 22:21:53 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 09FA28FC17 for ; Sun, 31 Jan 2010 22:21:52 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0VMLcIC023071; Sun, 31 Jan 2010 23:21:38 +0100 From: Pieter de Goeje To: James Mansion Date: Sun, 31 Jan 2010 23:21:37 +0100 User-Agent: KMail/1.9.10 References: <201001301816.16987.pieter@degoeje.nl> <201001311324.54206.pieter@degoeje.nl> <4B65E6D3.2010809@mansionfamily.plus.com> In-Reply-To: <4B65E6D3.2010809@mansionfamily.plus.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001312321.38447.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-java@freebsd.org Subject: Re: OpenJDK 6/7 kqueue based NIO provider X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 22:21:53 -0000 On Sunday 31 January 2010 21:23:47 James Mansion wrote: > Pieter de Goeje wrote: > > That is an interesting idea, such an implementation could potentially > > replace all existing back-ends with the exception of the Windows IOCP > > back-end. However libev doesn't seem to provide a non-blocking poll which > > is required for NIO (ev_loop always blocks AFAIK). > > I'll ask Marc. Would have thought that it wouldn't be too hard to > arrance an immediate timeout or to register a known-available fd too > (/dev/null?) I misread the the documentation, it is in fact possible to do a non-blocking poll using the aptly named EVLOOP_NONBLOCK flag :-) I do think that implementing nio using libev is more work than just using kqueue directly, because the libev API is more complex. Especially considering the fact that I now have an almost correctly working kqueue backend here :D. -- Pieter