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

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.

Common sense leads me to think that a close() should release
threads in IO operations (reads/writes/selects/polls) and
return EBADF or something appropriate. At least when behavior
is not dictated by POSIX or other historical/defactor behavior.

--
DE
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

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)