Date: Thu, 21 Dec 2006 11:40:31 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: Julian Elischer <jelischer@ironport.com>, David Xu <davidxu@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 Message-ID: <Pine.GSO.4.64.0612211136160.29290@sea.ntplx.net> In-Reply-To: <20061221152115.U83974@fledge.watson.org> References: <32874.1165905843@critter.freebsd.dk> <20061220153126.G85384@fledge.watson.org> <Pine.GSO.4.64.0612201308220.23942@sea.ntplx.net> <200612210820.09955.davidxu@freebsd.org> <4589E7D2.9010608@ironport.com> <20061221152115.U83974@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Dec 2006, Robert Watson wrote: > On Wed, 20 Dec 2006, Julian Elischer wrote: > >>> I think the main concern is if we will record every thread using a fd, >>> that means, when you call read() on a fd, you record your thread pointer >>> into the fd's thread list, when one wants to close the fd, it has to >>> notify all the threads in the list, set a flag for each thread, the flag >>> indicates a thread is interrupted because the fd was closed, when the >>> thread returns from deep code path to read() syscall, it should check the >>> flag, and return EBADF to user if it was set. whatever, a reserved signal >>> or TDF_INTERRUPT may interrupt a thread. but since there are many file >>> operations, I don't know if we are willing to pay such overheads to every >>> file syscall, extra locking is not welcomed. >> >> I think you are only intersted in treads that are sleeping.. so you allow a >> sleeping thread to save a pointer to the fd (or whatever) on which it is >> sleeping, along with the sleep address. >> >> items that are not sleeping are either already returning, or are going to >> sleep, in which case they can check at that time. > > Hence my question about select and poll: should they throw an exception state > when a file descriptor is closed out from under them? They often sleep on > hundreds or thousands of file descriptors, and not just one. Yes, I would think so. Solaris behaves this way also, although there seems to be a bug in Solaris 8 (version tested) in that select() returns -1 but errno isn't properly set (it is 0). -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0612211136160.29290>