Date: Mon, 13 May 2013 18:19:43 +0300 From: Eugen-Andrei Gavriloaie <shiretu@gmail.com> To: freebsd-hackers@freebsd.org Subject: Managing userland data pointers in kqueue/kevent Message-ID: <CCE4FFC4-F846-4F81-85EE-776B753C63C6@gmail.com>
index | next in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] 0 *H 01 0 + 0 *H 004=+'44pT0 *H 0o1 0 USE10U AddTrust AB1&0$U AddTrust External TTP Network1"0 UAddTrust External CA Root0 050607080910Z 200530104838Z01 0 UUS1 0 UUT10USalt Lake City1 0 U The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0"0 *H 0 9}A;bF7`u9eJGHjM5BI/ |1Nd.)բdąQ5yNh{ zɤ2 O0 nFxoY^/m/묡j.g5y iF͠ v:z'[=s "HaLi.1 ,CZ qYں gT: we tbh ~GeMW(t40b0, 00 U #0z4&&T$T0 U g}ĝ&p KPH|=n}0U 0U 00U 00U 0DU =0;09753http://crl.usertrust.com/AddTrustExternalCARoot.crl05+)0'0%+0http://ocsp.usertrust.com0 *H c(1{b#1sSQ L֟/g~x3t&dp bP#4Vp4nx7 _j̉_|>Q5|`k:+߳}[| P-sxt1^˚ƹ7urDg% R%G<N 6wH\-?`q`q 6 lKuI;ٟMx&-n_ 00mOj3""2zq0 *H 01 0 UUS1 0 UUT10USalt Lake City1 0 U The USERTRUST Network1!0 U http://www.usertrust.com1604U-UTN-USERFirst-Client Authentication and Email0 110428000000Z 200530104838Z01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0"0 *H 0 [KW^/@ȣSX_fe2N2}UxLUB'qi2@'Vbqi c^`ʢAj HmeC*.+c8w߱ڂ2jgo \5Tq 7 PSl Y1 LR@[HhJ$ :q_㬿;%qh=XF<hmz!W42~JRrd&N`ohQcB}"cөΞD\[5 K0G0 U #0g}ĝ&p KPH|=n}0 U zN t[xcd'/[y{0U 0U 0 0U 00U 0XU Q0O0MKIGhttp://crl.usertrust.com/UTN-USERFirst-ClientAuthenticationandEmail.crl0t+h0f0=+01http://crt.usertrust.com/UTNAddTrustClient_CA.crt0%+0http://ocsp.usertrust.com0 *H ־xWUm3DRB JAIZҭsn>&|L0(B<%> u=9fѡMo(l tZڱuz/y VtCr`9 G:eH<=%`I?C 3_н`j;:< I3B)93i.EMiڀ =]|Gm]W0KID~y83:]&XaU!ՙC@B0Ұun0#0 cOS LJCൕG0 *H 01 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CA0 120821000000Z 130821235959Z0"1 0 *H shiretu@gmail.com0"0 *H 0 GO}<tRusBI0}_ :F. 5qJ;d nzY2'lo~NЄ@]ո:f/SR> Aݘ&/(& kDLu@DW8 |Ep8Il 2 ?/O¤xjx͉g8͢Lt P g`>?# bZpdGܓOZQ>K ;g,ؙ 00 U #0zN t[xcd'/[y{0 U ZJU J' ;0U 0 U 0 0 U %0+ +10 `HB 0FU ?0=0; +10+0)+ https://secure.comodo.net/CPS0WU P0N0LJHFhttp://crl.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crl0+|0z0R+0Fhttp://crt.comodoca.com/COMODOClientAuthenticationandSecureEmailCA.crt0$+0http://ocsp.comodoca.com0 U 0shiretu@gmail.com0 *H s 33&U+ V[] jW+oC|F6#Jׁ ! K(*3pd5'kˑ<u f|JHA8yuFJW /k!,,]лvb֝nD\?ey,kϋ1h@KH9{ZPIe{÷'aŌtO@(ʹ6O j M%Ť a#Y}%HDL|"&>10001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CAcOS LJCൕG0 + 0 *H 1 *H 0 *H 1 130513151944Z0# *H 1a ip>.6c9+0 +71001 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CAcOS LJCൕG0 *H 101 0 UGB10UGreater Manchester10USalford10U COMODO CA Limited1907U0COMODO Client Authentication and Secure Email CAcOS LJCൕG0 *H 5CB#"B9TLP# ƖƽTsJVIj"&yȰP}tN X>t;1)~ 6D lj .wV([hIh>{Ѥ cN@UQ;3 5 g'nP=m#:K 2s[j* ~ A(sXEh-h=ul)܍|xųMCگGj2x^NgDC%l\ *(Sk]shelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CCE4FFC4-F846-4F81-85EE-776B753C63C6>