Date: 24 Apr 1997 01:42:21 +0200 From: fenyo@email.enst.fr (Alex Fenyo (eowyn)) To: Nanbor Wang <nw1@cs.wustl.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Possible broken libc_r Message-ID: <d06bu75paqq.fsf@nikopol.enst.fr> In-Reply-To: Nanbor Wang's message of Wed, 23 Apr 1997 16:24:05 -0500 References: <199704232124.QAA21626@siesta.cs.wustl.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d06bu75paqq.fsf>