Managing userland data pointers in kqueue/kevent

[Adrian Chadd]

... 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 at gmail.com> wrote:
> Hello to all,
>
> I'm trying to reply to this thread:
> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.html
>
> I also faced this very difficult task of tracking down the user data registered into kq.
> I end up having some "Tokens" instances which I never deallocate but always re-use them or create new ones if necessary. This tokens are used as user data for kq. They are keeping the actual pointers inside them, and the pointer itself has a reference to the Token. When the pointer dies, I reset the guts of the token. When the time comes to use the token, I have the guarantee 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 application shutdown, I cleanup the mess (the tokens). However, I just want to say 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 extremely 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 forcing user space code to do a lookup before use, instead of straightforward use. Not to mention the fact that we need to perform a lock before searching it. That brings havoc on kernel side on 1000+ active connections (a multi-threaded streaming server for example).
>
> I'm pretty sure this user data pointer is also breaking a well known pointer management paradigm, but I just can't remember which. Regardless, it has 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 faint 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 to 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
>