From owner-freebsd-hackers@FreeBSD.ORG  Thu Mar 19 10:01:57 2015
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 11071D0C
 for <freebsd-hackers@FreeBSD.org>; Thu, 19 Mar 2015 10:01:57 +0000 (UTC)
Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 7621F7DD
 for <freebsd-hackers@FreeBSD.org>; Thu, 19 Mar 2015 10:01:56 +0000 (UTC)
Received: from tom.home (kostik@localhost [127.0.0.1])
 by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2JA1pPm061433
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Thu, 19 Mar 2015 12:01:51 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2JA1pPm061433
Received: (from kostik@localhost)
 by tom.home (8.14.9/8.14.9/Submit) id t2JA1pFX061432;
 Thu, 19 Mar 2015 12:01:51 +0200 (EET)
 (envelope-from kostikbel@gmail.com)
X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com
 using -f
Date: Thu, 19 Mar 2015 12:01:51 +0200
From: Konstantin Belousov <kostikbel@gmail.com>
To: Ivan Radovanovic <radovanovic@gmail.com>
Subject: Re: kevent behavior
Message-ID: <20150319100151.GY2379@kib.kiev.ua>
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.23 (2014-03-12)
X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00,
 DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no
 autolearn_force=no version=3.4.0
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home
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
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 10:01:57 -0000

On Thu, Mar 19, 2015 at 07:33:06AM +0100, Ivan Radovanovic wrote:
> Hi guys,
> 
> 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)

The only special action taken by kqueue subsystem when a file descriptor
becomes invalid due to close, is the removal of all registered events
which reference the closing file descriptor. And, to prevent kqueue
code from stepping on its own toes, the close() call is put into
uninterruptible sleep with the "kqclose" wait channel until all
currently active kevent(2) calls release the references.