Date: Mon, 7 Jul 1997 11:26:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gurney_j@resnet.uoregon.edu Cc: wes@bogon.net, hackers@FreeBSD.ORG Subject: Re: Is there a thread-happy recv()? Message-ID: <199707071826.LAA18090@phaeton.artisoft.com> In-Reply-To: <19970706223705.64320@hydrogen.nike.efn.org> from "John-Mark Gurney" at Jul 6, 97 10:37:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707071826.LAA18090>