Date: Tue, 12 Dec 2006 23:12:00 -0800 From: Julian Elischer <julian@elischer.org> To: Bruce Evans <bde@zeta.org.au> Cc: "Arne H. Juul" <arnej@pvv.ntnu.no>, Daniel Eischen <deischen@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, David Xu <davidxu@freebsd.org>, freebsd-arch@freebsd.org, Kostik Belousov <kostikbel@gmail.com>, freebsd-java@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 Message-ID: <457FA7C0.408@elischer.org> In-Reply-To: <20061213141257.J2006@besplex.bde.org> References: <32874.1165905843@critter.freebsd.dk> <Pine.GSO.4.64.0612121543220.8780@sea.ntplx.net> <200612130730.10973.davidxu@freebsd.org> <20061213141257.J2006@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Wed, 13 Dec 2006, David Xu wrote: > >> On Wednesday 13 December 2006 04:49, Daniel Eischen wrote: >>> On Tue, 12 Dec 2006, Poul-Henning Kamp wrote: >>>> In message <20061212160016.W56465@delplex.bde.org>, Bruce Evans writes: >>>>> On Mon, 11 Dec 2006, Daniel Eischen wrote: >>>>> >>>>> It's probably a nightmare in the kernel too. close() starts looking >>>>> like revoke(), and revoke() has large problems and bugs in this area. >>>> >>>> There is the distinctive difference that revoke() operates on a name >>>> and close() on a filedescriptor, but otherwise I agree. >>> >>> Well, if threads waiting on IO are interruptable by signals, >>> can't we make a new signal that's only used by the kernel >>> and send it to all threads waiting on IO for that descriptor? >>> When it gets out to actually setup the signal handler, it >>> just resumes like it is returning from an SA_RESTART signal >>> handler (which according to another posting would reissue >>> the IO command and get EBADF). >> >> Stop using signal, it is slow for threaded process, first you don't >> know which threads are using the descriptor, second, you have >> to run long code path in kernel signal code to find and deliver >> the signals to all interested threads, that is too expensive for >> benchmark like apache benchmark. > > A signal would be fast enough for revoke() since revoke() is not used > much, and would work well if the signal could be sent, and is unmaskable, > and all device drivers catch signals (oops, all of them act like > applications whose signal catching function just sets a flag, except > while they sleep, so they have the usual problems with just setting a > flag -- they may run for too long before actually using the setting). > However, I think there is no way to determine which threads are using > an fd short of doing the equivalent of fstat(1) searching throuhj kmem. > Kernel data structures just aren't set up to do this search efficiently, > and shouldn't be bloated to do it. that's processes.. which thread in the process is the one that is currently waiting on the socket? > > For close() on non-devices, there is the additional problem of infinite > disk waits due to things like nfs servers down and bugs. Then signals > don't work and you wouldn't like close() by a thread trying to clean > up the problem to hang too. Otherwise close()/revoke() would be a good > way to cancel an infinite disk wait. > > Bruce > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?457FA7C0.408>