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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html