Date: Thu, 19 Mar 2015 11:49:00 +0100 From: Ivan Radovanovic <radovanovic@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: kevent behavior Message-ID: <550AA99C.5060102@gmail.com> In-Reply-To: <20150319100151.GY2379@kib.kiev.ua> References: <550A6DA2.1070004@gmail.com> <20150319100151.GY2379@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/19/15 11:01, Konstantin Belousov napisa: > 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. > So if I understand you correctly close(kfd) would simply block because kevent on same kqueue descriptor is in progress?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550AA99C.5060102>