Date: Mon, 13 May 2013 11:09:53 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Paul LeoNerd <leonerd@leonerd.org.uk> Cc: freebsd-hackers@freebsd.org, Eugen-Andrei Gavriloaie <shiretu@gmail.com> Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <CAJ-VmomQmPjtUhUo2%2BK=0Ychw-=qgawrZt3hnYeCPNNhA9T50A@mail.gmail.com> In-Reply-To: <20130513185357.1c552be5@shy.leonerd.org.uk> References: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com> <20130513185357.1c552be5@shy.leonerd.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 May 2013 10:53, Paul LeoNerd <leonerd@leonerd.org.uk> wrote: > [I'm not currently on the list so please forgive the manually-crafted > reply] > >> I'm confused as to why this is still an issue. Sure, fix the kqueue >> semantics and do it in a way that doesn't break backwards >> compatibility. > > I suggested that. Add a user->kernel flag > > EV_DROPWATCH > > which, if present, causes kernel to send back to userland events with > the kernel->user flag > > EV_DROPPING > > any time it drops the pointer. Then trivially userland just has to set > that flag on all its events to the kernel, and remember to send those > events back to userland when it does in fact drop them. Cool! Ok. I'll go bring this up at bsdcan and see what people think. I haven't been knee deep in this stuff for a few years (but am about to again, damned HTTP proxies!) and I would love to have better semantics here. I just want to make sure it doesn't cause weird things for the non-socket case - ie, files (local, NFS) and signals. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomQmPjtUhUo2%2BK=0Ychw-=qgawrZt3hnYeCPNNhA9T50A>