Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2006 15:56:47 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        freebsd-arch@freebsd.org, "Arne H. Juul" <arnej@pvv.ntnu.no>, David Xu <davidxu@freebsd.org>, freebsd-java@freebsd.org
Subject:   Re: close() of active socket does not work on FreeBSD 6
Message-ID:  <20061212135647.GK311@deviant.kiev.zoral.com.ua>
In-Reply-To: <Pine.GSO.4.64.0612120814460.6529@sea.ntplx.net>
References:  <Pine.LNX.4.62.0612111535280.32258@decibel.pvv.ntnu.no> <20061211171115.GD311@deviant.kiev.zoral.com.ua> <Pine.LNX.4.62.0612112259050.12159@decibel.pvv.ntnu.no> <200612120816.07608.davidxu@freebsd.org> <Pine.LNX.4.62.0612120142010.30236@decibel.pvv.ntnu.no> <Pine.GSO.4.64.0612111956110.2938@sea.ntplx.net> <Pine.GSO.4.64.0612120814460.6529@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--5uO961YFyoDlzFnP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 12, 2006 at 08:18:32AM -0500, Daniel Eischen wrote:
> On Mon, 11 Dec 2006, Daniel Eischen wrote:
>=20
> >On Tue, 12 Dec 2006, Arne H. Juul wrote:
> >
> >>On Tue, 12 Dec 2006, David Xu wrote:
> >>>On Tuesday 12 December 2006 06:34, Arne H. Juul wrote:
> >>><snip>
> >>>>This is exactly the sort of issue that should be solved by the
> >>>>thread library / kernel threads implementation and not in every
> >>>>threaded application that needs it, in my view.
> >>>>
> >>>It should not be done in new thread library, do you want a bloat
> >>>and error-prone thread library ? Instead if this semantic is really
> >>>necessary, it should be done in kernel.
> >>
> >>Well, it depends on the alternatives.
> >>If a clean kernel implementation is possible - yes please, of course.
> >>If only a complex, error-prone kernel implementation is possible,
> >>I would prefer to have the complexity in the thread library.
> >
> >Hacking libthr or libpthread to do this for you is not
> >an option.  They would then look like libc_r since all
> >fd's accesses would need to be wrapped.  If this needs
> >to be done, it must be in the kernel.
>=20
> It's also couldn't be entirely solved by fixing it in the
> threads library.  You could still have a non-threaded
> application that waits on a read operation, but receives
> a signal and closes the socket in the signal handler.

This is not the problem. The read (as syscall being executed) is aborted
when signal is delivered. Original poster considered situation where
read() is active (in particular, f_count of struct file is incremented
by fget, that caused the reported behaviour).

--5uO961YFyoDlzFnP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFFfrUeC3+MBN1Mb4gRAhCXAKCJxzJsY0KFk3GYwKTqTSC2ZLWybQCgjA8M
Lfnc6O8F144t8wd826jDuX0=
=6wvE
-----END PGP SIGNATURE-----

--5uO961YFyoDlzFnP--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061212135647.GK311>