This particular problem has come up many times over the years. So far
the standard strategy has been to ignore it. It's doubtful that the
complexity needed for a fix is worth it.
Workaround at user space level: call shutdown() first instead of close()
-Andi
-
To unsubscribe from this list: send
On Fri, Oct 26, 2007 at 03:09:01PM -0700, Stephen Hemminger wrote:
> > close() from another thread is not a way to abort blocked accept(). Never
> > promised to be that. Just as close() from another thread is not a way to
> > abort blocked write() or read() or sendmsg() or...
>
> The problem is
On Fri, 26 Oct 2007 22:45:13 +0100
Al Viro <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 26, 2007 at 02:03:19PM -0700, Stephen Hemminger wrote:
> > Looking at this bug:
> > http://bugzilla.kernel.org/show_bug.cgi?id=9149
> >
> > Exposes some rather deep issues in the filesystem/socket/inet/tcp
> > lay
On Fri, Oct 26, 2007 at 02:03:19PM -0700, Stephen Hemminger wrote:
> Looking at this bug:
> http://bugzilla.kernel.org/show_bug.cgi?id=9149
>
> Exposes some rather deep issues in the filesystem/socket/inet/tcp
> layering. It seems that sys_close() zaps the file table entry, but
> since each thread
Looking at this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=9149
Exposes some rather deep issues in the filesystem/socket/inet/tcp
layering. It seems that sys_close() zaps the file table entry, but
since each thread has a separate reference, the actual tcp_close()
doesn't happen until the last
