Date: Fri, 2 Dec 2011 14:16:51 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: freebsd-current@freebsd.org, imp@freebsd.org, Olivier Houchard <mlfbsd@kanar.ci0.org> Subject: Re: [patch] turning devctl into a "multiple openable" device Message-ID: <20111202121651.GT50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111201231721.GA1669@azathoth.lan> References: <20111130124320.GA1449@azathoth.lan> <201111301005.11938.jhb@freebsd.org> <20111130154636.GX50300@deviant.kiev.zoral.com.ua> <20111130155521.GA52567@ci0.org> <20111130160450.GY50300@deviant.kiev.zoral.com.ua> <20111130162017.GA53362@ci0.org> <20111201231721.GA1669@azathoth.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--g/Ej6EIvgQPzAS7S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2011 at 12:17:21AM +0100, Baptiste Daroussin wrote: > On Wed, Nov 30, 2011 at 05:20:17PM +0100, Olivier Houchard wrote: > > On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > > > I wonder why the waiting_threads stuff is needed at all. The cv c= ould > > > > > be woken up unconditionally everytime. What is the reason for the= cv_wait > > > > > call in cdevpriv data destructor ? You cannot have a thread doing= e.g. > > > > > read on the file descriptor while destructor is run. > > > > >=20 > > > >=20 > > > > What will prevent you from having a thread stuck in read(), while a= n another=20 > > > > one close() the fd ? > > > >=20 > > > Nothing, but file reference count goes to zero only after the thread > > > stuck in read is unstuck. Cdevpriv destructor is run only when file > > > reference count becomes zero, i.e. there can be no any accessing thre= ads, > > > and new accesses are impossible since file descriptors also own refer= ences > > > on the file. > >=20 > > Right, I was a bit confused, this part can be removed. > >=20 > > Regards, > >=20 > > Olivier >=20 > Here is a new version of the patch mostly reworked by Olivier, > It doesn't duplicate anymore the devq, and fix all that have been > spotted here previously. >=20 > http://people.freebsd.org/~bapt/devctl_multi_open.diff >=20 > bonus, it removes the needless giant lock I do not see a need in the use of refcount KPI, since it seems that all manipulations of n->refcount happen under global_devctl.mtx. Am I missed the place ? Releasing refcount on dev_event_info before using it in devread() allows other thread to free the memory while current thread still uses it. Stylish notes: mtx member in struct global_devctl has weird indentation; please move declaration of n2 into the declaration block of devdtor(); devread():should_free is initialized at the declaration site; devctl_queue_data_f() has stray empty line ater the while { loop line, while need blank line at the start of devctl_queue_data() is removed. --g/Ej6EIvgQPzAS7S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7YwbMACgkQC3+MBN1Mb4jhcgCgusZFXAgV/4wimRsgTFNE2TPW NBMAnA/j975qxzQ2jOemnxsLe0RyEom/ =aMaX -----END PGP SIGNATURE----- --g/Ej6EIvgQPzAS7S--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111202121651.GT50300>