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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Aug 12, 2010, 10:31 UTC
Message-ID: <4C63CD85.10304@viscovery.net>
In-Reply-To: <20100812102125.GA19498@LK-Perkele-V2.elisa-laajakaista.fi>

Am 8/12/2010 12:21, schrieb Ilari Liusvaara:

Show 15 quoted lines

> On Thu, Aug 12, 2010 at 11:23:39AM +0200, Johannes Sixt wrote:
> 
>>> * il/rfc-remote-fd-ext (2010-07-31) 4 commits
>>>  - Rewrite bidirectional traffic loop
>>>  - gitignore: Ignore the new /git-remote-{ext,fd} helpers
>>>  - New remote helper: git-remote-ext
>>>  - New remote helper git-remote-fd
>>
>> We do not have EWOULDBLOCK on Windows. Is it needed or could the
>> respective write() loop in remote-ext.c not be replaced by write_in_full()?
> 
> No, the writes can't be replaced by write_in_full() without changing what
> the code does, because write_in_full() retries short writes, whereas current
> code does not retry reads nor writes. And retrying reads/writes in code
> juggling with multiple fds is usally no-no.

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?

Show 10 quoted lines

> The EWOULDBLOCK is needed on some systems if fds involved are nonblocking[1]. I
> think the easiest way to handle system that has EAGAIN but not EWOULDBLOCK
> would be:
> 
> #ifndef EWOULDBLOCK
> #define EWOULDBLOCK EGAIN
> #endif
> 
> [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?

-- Hannes