Date: Mon, 13 May 2013 08:25:16 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Eugen-Andrei Gavriloaie <shiretu@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <CAJ-VmokBfBvdLa_Wf2EajF%2BvecVntLDaxdVeNvhAOiPp6HkjNA@mail.gmail.com> In-Reply-To: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com> References: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
... or you could just track the per-descriptor / per-object stuff in userland, and use the FD/signal as an index into the state you need. adding thread happiness on top of that is trivial. Done/done. Adrian On 13 May 2013 08:19, Eugen-Andrei Gavriloaie <shiretu@gmail.com> wrote: > Hello to all, > > I'm trying to reply to this thread: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.h= tml > > I also faced this very difficult task of tracking down the user data regi= stered into kq. > I end up having some "Tokens" instances which I never deallocate but alwa= ys re-use them or create new ones if necessary. This tokens are used as use= r data for kq. They are keeping the actual pointers inside them, and the po= inter itself has a reference to the Token. When the pointer dies, I reset t= he guts of the token. When the time comes to use the token, I have the guar= antee is not the corpse of a token (never deallocate them, remember?) and I= can see that the actual pointer was gone, everyone is happy. At the applic= ation shutdown, I cleanup the mess (the tokens). However, I just want to sa= y that Paul has a valid point when he is wondering why EV_FREEWATCH was not= provisioned/implemented. > > The moment we throw multi-threading into equation, this becomes a extreme= ly hard thing to manage (close to impossible), including my "proven-to-work= " Token trick. It renders the user data pointer completely useless because= in the end we need to keep an association map inside user space. That is f= orcing user space code to do a lookup before use, instead of straightforwar= d use. Not to mention the fact that we need to perform a lock before search= ing it. That brings havoc on kernel side on 1000+ active connections (a mul= ti-threaded streaming server for example). > > I'm pretty sure this user data pointer is also breaking a well known poin= ter management paradigm, but I just can't remember which. Regardless, it ha= s all the ingredients for memory leaks and/or, the worst one, use of corpse= pointers which are bound to crash the app. I agree, C/C++ is not for the f= aint of heart, but with little or close to no efforts, his EV_FREEWATCH can= be put to very good use, and user space code not only becomes less prone t= o mem issues, but also cleaner. > > To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean and = very very efficient. > > Best regards, > Andrei > > ------ > Eugen-Andrei Gavriloaie > Web: http://www.rtmpd.com >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokBfBvdLa_Wf2EajF%2BvecVntLDaxdVeNvhAOiPp6HkjNA>