Re: What's cooking in git.git (Aug 2010, #02; Wed, 11)

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Greg Brockman <gdb@MIT.EDU>, Elijah Newren <newren@gmail.com>
Subject: Re: What's cooking in git.git (Aug 2010, #02; Wed, 11)
Date: Thu, 12 Aug 2010 18:25:32 +0300	[thread overview]
Message-ID: <20100812152532.GA19956@LK-Perkele-V2.elisa-laajakaista.fi> (raw)
In-Reply-To: <4C63CD85.10304@viscovery.net>

On Thu, Aug 12, 2010 at 12:31:33PM +0200, Johannes Sixt wrote:
>
> builtin/remote-ext.c uses a loop that looks very much like what
> write_in_full() does; transport-helper.c's checks for EAGAIN look very
> similar to xwrite(). Why can't you reuse these functions?

Ah, the request sending loop (send_git_request()), not the bidirectional loop
(my bad). Yes, that function can be simplified a lot (patch sent).

> > [1] Some systems return EAGAIN on read/write failed due to blocking (with
> > EAGAIN == EWOULDBLOCK), others return EWOULDBLOCK.
> 
> But shouldn't then xwrite() and xread() be extended to check also for
> EWOULDBLOCK?

Based on what I understand, yes. read() and write() that fails due to blocking
being needed but disabled returns EWOULDBLOCK, which may or may not be the
same as EAGAIN, so the return value in no-blocking case equals EAGAIN only
if EAGAIN == EWOULDBLOCK, which isn't guaranteed.

Have a macro that does the non-fatal error check?

-Ilari