... 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 <[email protected]> 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 > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
