From owner-freebsd-arch Wed Dec 4 12:15:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 423A037B401 for ; Wed, 4 Dec 2002 12:15:10 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4945243ED8 for ; Wed, 4 Dec 2002 12:15:09 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2002120420150700100qnqg3e>; Wed, 4 Dec 2002 20:15:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27434; Wed, 4 Dec 2002 12:12:42 -0800 (PST) Date: Wed, 4 Dec 2002 12:12:41 -0800 (PST) From: Julian Elischer To: Robert van Engelen Cc: freebsd-arch@freebsd.org Subject: Re: Mac OS X BSD SO_NOSIGPIPE bug In-Reply-To: <7BF5285B-07A1-11D7-8EA1-000393C3075E@cs.fsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 4 Dec 2002, Robert van Engelen wrote: Firstly, or course, a FreeBSD list is an odd place to ask a macOS question.. But, assuming that there might be an inherritted bug from FreeBSD, a sample test program would be a good start. > I recently ran into a nasty problem with BSD-based Mac OS X Darwin and > sockets with SO_NOSIGPIPE and SO_KEEPALIVE both enabled (setsockopt). > The problem is with bind(), accept() followed by multiple send() and > recv() calls. Eventually, the send() and/or recv() will stall for > several minutes, even though data is available. Monitoring the TCP/IP > traffic I found that the send() and/or recv() loops while attempting to > get more data or send data in 5 second intervals. Eventually this > succeeds after several minutes delay. The problem does not occur when I > use my own SIGPIPE signal handler, nor does it occur on Linux or other > UNIX platforms. I also removed the handler and all works fine in that > case as well. So even when the connections are not prematurely > terminated, the SO_NOSIGPIPE option causes this problem. Does anyone > have an idea? Has this behavior been observed before? Is this normal > behavior? > > - Dr. Robert van Engelen, Florida State University > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message