Date: Thu, 19 Mar 2015 12:01:51 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ivan Radovanovic <radovanovic@gmail.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: kevent behavior Message-ID: <20150319100151.GY2379@kib.kiev.ua> In-Reply-To: <550A6DA2.1070004@gmail.com> References: <550A6DA2.1070004@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150319100151.GY2379>