From owner-freebsd-bugs@FreeBSD.ORG Mon Jul 25 18:30:16 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12BD3106568F for ; Mon, 25 Jul 2011 18:30:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 024098FC1A for ; Mon, 25 Jul 2011 18:30:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6PIUFJj059415 for ; Mon, 25 Jul 2011 18:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6PIUFwj059410; Mon, 25 Jul 2011 18:30:15 GMT (envelope-from gnats) Date: Mon, 25 Jul 2011 18:30:15 GMT Message-Id: <201107251830.p6PIUFwj059410@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Michael Gmelin Cc: Subject: Re: kern/159179: [libc] close(2) emitting ECONNRESET is not POSIX compliant X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Gmelin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:30:16 -0000 The following reply was made to PR kern/159179; it has been noted by GNATS. From: Michael Gmelin To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159179: [libc] close(2) emitting ECONNRESET is not POSIX compliant Date: Mon, 25 Jul 2011 20:29:00 +0200 Thinking about this, even the previous behavior (returning EINVAL) was = not POSIX.1 compliant (at least as far as I understand the standard). = The author of the patch clearly states that he thinks it is compliant, = so it would be interesting to see what his perception is based on. It = would also be good to get a better understanding of why this error is = emitted in the first place (I got a rough understanding of how the pcb's = come into play here) and why this seems to happen more frequently now = (finer grained locking, multithreading etc.). FInally it would be = interesting to know if this is connected to the rewrites that have taken = place between 7 and 8. Ultimately I think whatever is going on behind = the scenes, the high level API calls should be POSIX compliant - = alternatively the documentation/man pages should clearly state, where = they're not.