From owner-freebsd-hackers  Mon Jul  7 11:31:13 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA29271
          for hackers-outgoing; Mon, 7 Jul 1997 11:31:13 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA29264
          for <hackers@FreeBSD.ORG>; Mon, 7 Jul 1997 11:31:09 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA18090; Mon, 7 Jul 1997 11:26:04 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199707071826.LAA18090@phaeton.artisoft.com>
Subject: Re: Is there a thread-happy recv()?
To: gurney_j@resnet.uoregon.edu
Date: Mon, 7 Jul 1997 11:26:04 -0700 (MST)
Cc: wes@bogon.net, hackers@FreeBSD.ORG
In-Reply-To: <19970706223705.64320@hydrogen.nike.efn.org> from "John-Mark Gurney" at Jul 6, 97 10:37:05 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Wes Santee scribbled this message on Jul 6:
> > Hi all.  I noticed in a chunk of code I'm writing that a blocking call
> > to recv() is putting the entire process to sleep such that even the
> 
> don't use recv, use read instead...  the reason recv isn't wrapped is
> that wrapping it is pointless, and may be removed in the future (from
> man page)

What about recvfrom()?

The reason cited for it's redundancy is its identity with recvfrom()
with a nil parameter.

In any case, the socket should be non-blocking, right?

I think the problem is elsewhere.

I *know* that read() is useless for distinguishing OOB data.

I also suspect that the recvfrom() may not be appropriate, given
the connection identification hack (select comes true on a
connection, and then you get the address before issuing an accept()
to determine if you want to accept() or close() the socket based on
who originated the connection -- see Stevens...).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.