Date: Mon, 12 Jun 2006 15:09:52 +0200 From: Divacky Roman <xdivac02@stud.fit.vutbr.cz> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Robert Watson <rwatson@freebsd.org>, current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: FILEDESC_LOCK() implementation Message-ID: <20060612130952.GA94370@stud.fit.vutbr.cz> In-Reply-To: <34100.1150098013@critter.freebsd.dk> References: <20060612080504.W26634@fledge.watson.org> <34100.1150098013@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 12, 2006 at 07:40:13AM +0000, Poul-Henning Kamp wrote: > In message <20060612080504.W26634@fledge.watson.org>, Robert Watson writes: > > >At least in the VFS and socket code, you want a notion of acquiring both and > >dropping one, or upgrading/downgrading. The logic tends to go something like > >this: > > That's different from what FILEDESC needs. FILEDESC has two different > classes of operations: cheap/non-sleeping and expensive/sleeping I made a patch: http://hysteria.sk/~neologism/filedesc.patch which improves the situation on UP, it was even commited but then backed out because there are places where FILEDESC_[UN]LOC_FAST is used to protect operations which can sleep... I think there's just one or two such places but dont have time to work on this (I am busy with SoC) but is shoudl be quite trivial to find them (the number of places where we use _FAST locking is not very big) roman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060612130952.GA94370>