Re: [PATCH 1/2] run-command: Remove set_nonblocking

On Thu, Nov 5, 2015 at 12:27 PM, Johannes Sixt wrote: > However, I think that the infrastructure can be simplified even further > to a level that we do not need additional emulation on Windows. > > First let me say that I find it very questionable that the callbacks > receive a

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Am 06.11.2015 um 20:00 schrieb Stefan Beller: On Thu, Nov 5, 2015 at 12:27 PM, Johannes Sixt wrote: Here is a prototype patch. Feel free to pick it up. It marks a process whose EOF we have found by setting .err to -1. It's probably better to extend the meaning of the in_use

Re: [PATCH 1/2] run-command: Remove set_nonblocking

On Thu, Nov 5, 2015 at 10:45 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> strbuf_read_once can also operate on blocking file descriptors if we are >> sure they are ready. The poll (2) command however makes sure this is the >> case. >> >> Reading

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Stefan Beller writes: > On Thu, Nov 5, 2015 at 10:45 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> strbuf_read_once can also operate on blocking file descriptors if we are >>> sure they are ready. The poll (2) command

[PATCH 1/2] run-command: Remove set_nonblocking

strbuf_read_once can also operate on blocking file descriptors if we are sure they are ready. The poll (2) command however makes sure this is the case. Reading the manual for poll (2), there may be spurious returns indicating readiness but that is for network sockets only. Pipes should be

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Stefan Beller writes: > strbuf_read_once can also operate on blocking file descriptors if we are > sure they are ready. The poll (2) command however makes sure this is the > case. > > Reading the manual for poll (2), there may be spurious returns indicating > readiness but

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Am 05.11.2015 um 19:17 schrieb Stefan Beller: > strbuf_read_once can also operate on blocking file descriptors if we are > sure they are ready. The poll (2) command however makes sure this is the > case. > > Reading the manual for poll (2), there may be spurious returns indicating > readiness but

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Johannes Sixt writes: > Am 05.11.2015 um 19:17 schrieb Stefan Beller: >> strbuf_read_once can also operate on blocking file descriptors if we are >> sure they are ready. The poll (2) command however makes sure this is the >> case. >> >> Reading the manual for poll (2), there may

Re: [PATCH 1/2] run-command: Remove set_nonblocking

On Thu, Nov 5, 2015 at 12:27 PM, Johannes Sixt wrote: > diff --git a/run-command.c b/run-command.c > index 51d078c..3e42299 100644 > --- a/run-command.c > +++ b/run-command.c > @@ -977,7 +977,7 @@ static struct parallel_processes *pp_init(int n, > for (i = 0; i < n; i++) {

Re: [PATCH 1/2] run-command: Remove set_nonblocking

Am 05.11.2015 um 23:20 schrieb Stefan Beller: On Thu, Nov 5, 2015 at 12:27 PM, Johannes Sixt wrote: diff --git a/run-command.c b/run-command.c index 51d078c..3e42299 100644 --- a/run-command.c +++ b/run-command.c @@ -977,7 +977,7 @@ static struct parallel_processes *pp_init(int