Date: Fri, 25 Apr 1997 08:24:59 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: fenyo@email.enst.fr (Alex Fenyo eowyn) Cc: nw1@cs.wustl.edu, freebsd-hackers@freebsd.org Subject: Re: Possible broken libc_r Message-ID: <199704242225.IAA02009@freebsd1.cimlogic.com.au> 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
Alex Fenyo (eowyn) wrote:
> 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.
AFAIK, libc_r doesn't need to wrapper send() and recv() because these
are already wrappers in libc/net for sendto() and recvfrom() which
_are_ wrappered.
>
> Sincerly,
> Alexandre Fenyo
>
Regards,
--
John Birrell - jb@cimlogic.com.au; jb@netbsd.org; jb@freebsd.org
CIMlogic Pty Ltd, 119 Cecil Street, South Melbourne Vic 3205, Australia
Tel +61 3 9690 6900 Fax +61 3 9690 6650 Mob +61 418 353 137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704242225.IAA02009>