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

From: Johannes Sixt <[email-masked]>
Date: Thu, 12 Aug 2010 12:31:33 +0200

Am 8/12/2010 12:21, schrieb Ilari Liusvaara:
> 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?

> 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