This definitely should block, not return EINVAL. Basically
it should behave identical to pipes.

Jaromir

Jesse Off wrote:
> When the receive buffer fills in one socket from a
> socketpair(PF_LOCAL, SOCK_DGRAM), I've noticed that
> subsequent write()s to the other socket will fail with
> EINVAL.  Is this by design?  If it is, is EINVAL the
> correct errno to return here?   Solaris and Linux seem
> to agree to block when the buffers fill, that would be
> ideal in my case, but I'd even settle for a better
> return errno.  EINVAL leads me to believe I'm passing
> bad pointers, which I'm not.  Here's the test code
> that will fail the written assert():
> 
> #include <sys/socket.h>
> #include <errno.h>
> #include <assert.h>
> 
> int main(void)
> {
>   char buf[1024];
>   int sk[2];
>   int ret = 0;
>   socketpair(PF_LOCAL, SOCK_DGRAM, 0, sk);
> 
>   while(ret != -1)
>     ret = write(sk[0], buf, 1024);
>   assert(errno != EINVAL);
> }
> 
> I'm running this on 1.6.1, but based on a quick look
> at the code in -current from cvs I'm guessing its
> present in there to.  The culprit seems to
> unp_output() in uipc_usrreq.c returning the EINVAL
> when the sbappendaddr() to the buddy socket's receive
> buffer returns 0.
> 
> //Jesse Off
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
> 


-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-