Date: Tue, 24 May 2005 21:30:50 -0400 From: Ed Maste <emaste@phaedrus.sandvine.ca> To: freebsd-stable@freebsd.org Subject: Re: libc_r kqueue fd leak Message-ID: <20050525013050.GC35718@sandvine.com> In-Reply-To: <20050524230131.GN959@funkthat.com> References: <20050524165907.GA20674@sandvine.com> <20050524173648.GA29183@sandvine.com> <20050524215153.GA35718@sandvine.com> <20050524230131.GN959@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 24, 2005 at 04:01:31PM -0700, John-Mark Gurney wrote: > yes, the reason I made _stat return ENXIO is that _read and _write are > not supported by kqueue, and so _stat provided useless information. > When I added locking, it would only be reading a value that would > immediately be able to be changed, making it informational at best.. > You'd better spend your syscall calling kevent and getting a few > events off the queue than trying to figure out how much work you > have to do... (In one of my programs, I have code that dynamicly > increases the number of kevent structs I pull off if I get the max..) > > After being pestered by ps, I have created a patch.. after a quick test > that it compiles and runs, I'll commit it... Though libc_r depending > upon _stat seems broken to me... Who knows what else doesn't implement > _stat and can't be closed.. Thanks for committing that. I agree that it's goofy for libc_r to depend on stat, hence the libc_r uthread_close patch I posted. Unfortunately that would require a 4.x libc_r for compat too. -ed
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050525013050.GC35718>