From owner-freebsd-hackers  Wed Apr 23 23:46:47 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA19752
          for hackers-outgoing; Wed, 23 Apr 1997 23:46:47 -0700 (PDT)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA19747
          for <freebsd-hackers@freebsd.org>; Wed, 23 Apr 1997 23:46:44 -0700 (PDT)
Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id IAA15372; Thu, 24 Apr 1997 08:55:07 +0200 (MET DST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199704240655.IAA15372@ocean.campus.luth.se>
Subject: Re: Possible broken libc_r
To: fenyo@email.enst.fr (Alex Fenyo (eowyn))
Date: Thu, 24 Apr 1997 08:55:06 +0200 (MET DST)
Cc: freebsd-hackers@freebsd.org
In-Reply-To: <d06bu75paqq.fsf@nikopol.enst.fr> from "Alex Fenyo (eowyn)" at "Apr 24, 97 01:42:21 am"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
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

According to Alex Fenyo (eowyn):
> 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.

Why doesn't it implement a wrapper for it? Is it not done yet, or is it
the intention to leave it broken?

  /Mikael