From owner-freebsd-hackers@FreeBSD.ORG Mon May 13 17:06:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D31C3976 for ; Mon, 13 May 2013 17:06:40 +0000 (UTC) (envelope-from leonerd@leonerd.org.uk) Received: from cel.leonerd.org.uk (cel.leonerd.org.uk [IPv6:2001:8b0:3f7::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BF36988 for ; Mon, 13 May 2013 17:06:40 +0000 (UTC) Received: from shy.leonerd.org.uk (8.9.7.8.3.c.e.f.f.f.2.8.9.a.e.8.3.4.0.0.7.f.3.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:3f7:43:8ea9:82ff:fec3:8798]) by cel.leonerd.org.uk (Postfix) with ESMTPSA id F207B1BDF9; Mon, 13 May 2013 18:06:38 +0100 (BST) Date: Mon, 13 May 2013 18:06:37 +0100 From: Paul "LeoNerd" Evans To: Eugen-Andrei Gavriloaie Subject: Re: Managing userland data pointers in kqueue/kevent Message-ID: <20130513180637.6ff6b7d6@shy.leonerd.org.uk> In-Reply-To: References: X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/QkKqArvT/PY+r3oxcIAmFBv"; protocol="application/pgp-signature" X-Mailman-Approved-At: Mon, 13 May 2013 17:28:06 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:06:40 -0000 --Sig_/QkKqArvT/PY+r3oxcIAmFBv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 May 2013 18:19:43 +0300 Eugen-Andrei Gavriloaie wrote: > 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. >=20 > To summarise, +1 for the EV_FREEWATCH. I simply love the idea! Clean > and very very efficient. I actually developed the idea a little further and put some notes on implementation/etc here in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D153254 I don't think anyone has looked at it though. If anyone were to just say "yes" and explain how to start developing a kernel feature, I'm sure I'd be happy to look into it. --=20 Paul "LeoNerd" Evans leonerd@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ --Sig_/QkKqArvT/PY+r3oxcIAmFBv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGRHZ0ACgkQvLS2TC8cBo2uugCfdivAovpEzmx4Lb9cFzOkycFC XGQAoPwS4/JFhOn8ktJhU8Z5jVaqUKm6 =Meuq -----END PGP SIGNATURE----- --Sig_/QkKqArvT/PY+r3oxcIAmFBv--