From owner-freebsd-hackers  Wed Apr 23 16:42:56 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id QAA00910
          for hackers-outgoing; Wed, 23 Apr 1997 16:42:56 -0700 (PDT)
Received: from inf.enst.fr (R8utL+fQ5QCTRl6aK7t8Ie+Xw4lwRrbY@inf.enst.fr [137.194.2.81])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA00901
          for <freebsd-hackers@freebsd.org>; Wed, 23 Apr 1997 16:42:53 -0700 (PDT)
Received: from email.enst.fr (email.enst.fr [137.194.168.17])
          by inf.enst.fr (8.8.4/8.8.4) with ESMTP
	  id BAA15007; Thu, 24 Apr 1997 01:42:45 +0200 (MET DST)
Received: from nikopol.enst.fr (nikopol.enst.fr [137.194.168.105])
          by email.enst.fr (8.8.4/8.8.4) with ESMTP
	  id BAA16936; Thu, 24 Apr 1997 01:42:36 +0200 (MET DST)
Received: (from fenyo@localhost)
          by nikopol.enst.fr (8.8.4/8.8.4)
	  id BAA16940; Thu, 24 Apr 1997 01:42:34 +0200 (MET DST)
To: Nanbor Wang <nw1@cs.wustl.edu>
Cc: freebsd-hackers@freebsd.org
X-WWW: http://home.eowyn.fr.eu.org/~fenyo/documents/axel.html
X-PGP-Key: finger alex@eowyn.fr.eu.org
X-NIC-Handle: AF713
X-Whois: whois -h whois.internic.net fenyo
X-Pager: 06-04-30-75-94 (for emergency only)
Organization: Ecole Nationale Superieure des Telecommunications de Paris
Subject: Re: Possible broken libc_r
References: <199704232124.QAA21626@siesta.cs.wustl.edu>
From: fenyo@email.enst.fr (Alex Fenyo (eowyn))
Date: 24 Apr 1997 01:42:21 +0200
In-Reply-To: Nanbor Wang's message of Wed, 23 Apr 1997 16:24:05 -0500
Message-ID: <d06bu75paqq.fsf@nikopol.enst.fr>
Lines: 30
X-Mailer: Red Gnus v0.50/XEmacs 19.14
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

Nanbor Wang <nw1@cs.wustl.edu> writes:
> I found a possible bug in libc_r.  Below is a very simple test
> program.  What I did was I opened a socket in the localhost between
> client and server program.  When I compiled the program with
> non-threaded library, everything worked just fine.  However, when I
> compiled it using libc_r, the recv() system call seemed to be broken.
> Without any specific manipulation, it acted as if I had turn on the
> non-blocking flag.  Is this a bug or I did something terribly wrong?

It's not a bug, it's a feature :-)
With libc_r, each file descriptor, just after creation, is changed
to a non blocking state, for the convenience of libc_r.
It's most of the time hidden for the user, because libc_r remembers
the original state ("blocking" or not), and when a thread
makes a call on a blocking descriptor, libc_r makes a non blocking
call but if the call returns EAGAIN, libc_r removes the process
from the running queue. Later, when the call can be performed,
libc_r requeue the calling thread.
Libc_r adds a wrapper for each system call, to handle this mechanism.
BUT libc_r doesn't implement a wrapper for send() and recv().
To bypass your problem, use sendto() and recvfrom() instead.

Sincerly,
Alexandre Fenyo