Re: close() of active socket does not work on FreeBSD 6

On Tue, Dec 12, 2006 at 08:18:32AM -0500, Daniel Eischen wrote:
On Mon, 11 Dec 2006, Daniel Eischen wrote:

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.

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).

Attachment: pgp02JpjqjxCl.pgp
Description: PGP signature

Relevant Pages

  • Re: New Patch Fixes 43 Flaws In OS X, Many Serious
    ... A product being a "Unix" has no security implications ... Mac OS X would then become higher ... So it is with any kernel, ...
    (comp.sys.mac.advocacy)
  • Re: Story Time
    ... In this case, the General Public License says that "you" can freely use "his" code, but that if you distribute the subsequent binaries to anyone else, you must share your changes with "them". ... the GPL encourages you to charge money for shipping your code to your distributees. ... difference ins the kernel between the two versions. ...
    (comp.os.vms)
  • Re: /etc/udev/rules.d and permissions in /dev/usb
    ... > - `udevsynthesize', which writes to all those uevent files, following ... > you can't easily unplug a disk partition; you can rely on whole disk block ... >>> I personally consider even using the kernel device numbering, %n, to be ...
    (uk.comp.os.linux)
  • Re: whats next for the linux kernel?
    ... kernel code is orders of magnitude ... And multi-core processors aren't really new technology - there ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Something overriding udev for hotplug events?
    ... kernel: Additional sense: Not ready to ready change, ... kernel: sdd: READ CAPACITY failed. ... kernel: sdd: assuming drive cache: write through ...
    (Debian-User)