From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 22:15:44 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E71A15D7 for ; Tue, 24 Mar 2015 22:15:44 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ACA46A0 for ; Tue, 24 Mar 2015 22:15:44 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 6DEEA3592F1; Tue, 24 Mar 2015 23:15:41 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 5C8BA28494; Tue, 24 Mar 2015 23:15:41 +0100 (CET) Date: Tue, 24 Mar 2015 23:15:41 +0100 From: Jilles Tjoelker To: Ivan Radovanovic Subject: Re: kevent behavior Message-ID: <20150324221541.GA67584@stack.nl> References: <550A6DA2.1070004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <550A6DA2.1070004@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:15:45 -0000 On Thu, Mar 19, 2015 at 07:33:06AM +0100, Ivan Radovanovic wrote: > Is there defined (and guaranteed) behavior of kevent if kqueue FD is > being closed while blocking kevent call is in progress? > Possible scenario would be like this: > Thread 1: > ... > kfd = kqueue(); > ... > // create second thread afterwords > // and do blocking wait for events > result = kevent(kfd, changelist, nchanges, eventlist, nevents, NULL); > if (result == -1) > // check if there was request to stop listening for events > Thread 2: > // do something > // then close kqueue's fd > close(kfd); > I am asking this because file watcher implementation for mono is > implemented that way (which I find nicer than using timeout), but this > is apparently based on expected kevent behavior under Darwin, and I > can't find any mention that in FreeBSD kevent is going to behave the > same way (at least not on kqueue(2) manual page) This method is inherently unsafe, since you cannot be sure thread 1 has started blocking in kevent() when you close() in thread 2. If not, there might be a thread 3 creating a kqueue between thread 2's close and thread 1's kevent, and thread 1 will manipulate the new kqueue. Fortunately, EVFILT_USER provides an easy way to wake up a thread blocked in kevent(). If kevent() was implemented as a cancellation point, pthread_cancel() would be another option, but it is not. -- Jilles Tjoelker