From owner-freebsd-hackers Fri Jul 30 2: 8:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id BB25F151DE for ; Fri, 30 Jul 1999 02:08:29 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id MAA02172; Fri, 30 Jul 1999 12:01:42 +0300 (EEST) (envelope-from will) To: wes@softweyr.com (Wes Peters) Cc: hackers@freebsd.org Subject: Re: Documenting writev(2) ENOBUFS error References: <19990728170119.A47890@kilt.nothing-going-on.org> <37A06B6B.B5BF74CF@softweyr.com> From: Ville-Pertti Keinonen Date: 30 Jul 1999 12:01:42 +0300 In-Reply-To: wes@softweyr.com's message of "29 Jul 1999 17:58:06 +0300" Message-ID: <86yafy5x55.fsf@not.demophon.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wes@softweyr.com (Wes Peters) writes: > [ENOBUFS] Insufficient system buffer space exists to complete the op- > eration. Do you know what kind of circumstances that error *really* occurs under? If it happened with files, that would be a bug and should be fixed. The call is supposed to block to wait for writes to be possible. This applies to stream sockets in most cases, as well. Based on a quick look at the code, out-of-band TCP data seems to be the only case where ENOBUFS might be returned for streams, and that obviously doesn't apply to write/writev. As I mentioned to Nik in private mail, for datagram sockets, the description in send(2) more or less applies. Programs should generally use send rather than write for such objects, anyhow. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message