Hi, Well, Paul already asked this question like 3-4 times now. Even insisting on it. I will also ask it again: If user code is responsible of tracking down the data associated with the signalled entity, what is the point of having user data? Is rendered completely useless…
Not to mention, that your suggestion with FD index is a definite no-go. The FD values are re-used. Especially in MT environments. Imagine one kqueue call taking place in thread A and another one in thread B. Both threads waiting for events. When A does his magic, because of internal business rules, it decides to close FD number 123. It closes it and it connects somewhere else by opening a new one. Surprise, we MAY get the value 123 again as a new socket, we put it on our index, etc. Now, thread B comes in and it has stale/old events for the old 123 FD. Somethings bad like EOF for the OLD version of FD number 123 (the one we just closed anyway). Guess what… thread B will deallocate the perfectly good thingy inside the index associated with 123. And regarding the "thread happiness", that is not happiness at all IMHO… Best regards, Andrei ------ Eugen-Andrei Gavriloaie Web: http://www.rtmpd.com On May 13, 2013, at 6:25 PM, Adrian Chadd <adr...@freebsd.org> wrote: > ... 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 <shir...@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 >>
smime.p7s
Description: S/MIME cryptographic signature
