Date: Thu, 24 Apr 1997 08:55:06 +0200 (MET DST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: fenyo@email.enst.fr (Alex Fenyo (eowyn)) Cc: freebsd-hackers@freebsd.org Subject: Re: Possible broken libc_r Message-ID: <199704240655.IAA15372@ocean.campus.luth.se> In-Reply-To: <d06bu75paqq.fsf@nikopol.enst.fr> from "Alex Fenyo (eowyn)" at "Apr 24, 97 01:42:21 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704240655.IAA15372>