Date: Sun, 22 Sep 2002 21:38:40 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: Jeff Roberson <jroberson@chesapeake.net>, Greg 'groggy' Lehey <grog@FreeBSD.org>, Jeff Roberson <jeff@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_alq.c src/sys/sys alq.h Message-ID: <20020922213840.A99514@FreeBSD.org> In-Reply-To: <20020923042448.GF6262@elvis.mu.org>; from bright@mu.org on Sun, Sep 22, 2002 at 09:24:48PM -0700 References: <20020923003727.GM21093@wantadilla.lemis.com> <20020922211607.E43954-100000@mail.chesapeake.net> <20020923020717.GC6262@elvis.mu.org> <20020922202803.A95505@FreeBSD.org> <20020923042448.GF6262@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* De: Alfred Perlstein <bright@mu.org> [ Data: 2002-09-22 ] [ Subjecte: Re: cvs commit: src/sys/kern kern_alq.c src/sys/sys alq.h ] > * Juli Mallett <jmallett@FreeBSD.org> [020922 20:28] wrote: > > * De: Alfred Perlstein <bright@mu.org> [ Data: 2002-09-22 ] > > [ Subjecte: Re: cvs commit: src/sys/kern kern_alq.c src/sys/sys alq.h ] > > > Have you thought of running it into a fifo with gzip waiting on the > > > other side? I guess that could sort of cause an infinite loop if > > > you were recording certain process/vnode interaction unless it was > > > batched up somehow. > > > > Add an ALQ mutex to a vnode, and check for recursion? > > It's not really recursion, it's the fact that running gzip may cause > more information to be written to the pipe that gzip is reading from. > > I think adding an ALQ _flag_ (you meant flag right?) to the proc > struct to prevent ~recursion~ would work. Yeah, that'd be right, I was just thinking in a roundabout sort of way so that a lock is held as data is written to the ALQ, and then when gzip would cause more to be written, BAM, or just silently ignore, probably depending on flags passed. I think though that if this is intended for vnode stuff, then recursion must be accounted for somewhere. > Then again I am wildly speculating about something I should probably > UTSL about first. :) Same. I suspect I'll be learning how to toy with it soon enough ;) I suspect this is all to facilitate the legendary "vnode not locked" / "vnode already locked" problems seen many places, by making a machine- parsable file, so that the missing lock/unlock can be found? -- Juli Mallett <jmallett@FreeBSD.org> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020922213840.A99514>