dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

Hi Sebastian,

On Thu, 2010-11-11 at 16:49 +0100, Sebastian Egner wrote:
> On 11.11.10 15:20, Jelmer Vernooij wrote:
> > We'd need an alternative way to determine whether there's data available
> > from a subprocess. I'm not sure what the best way to do that is on
> > Windows. The subprocess module doesn't provide any hints about this.
> Your are right, of course. I checked: The object proc.stdout will be a
> Python 'file' object on Windows---and these don't come with a method of
> polling, unless the entire file is switched into asynchronous mode.
Switching the file to some sort of non-blocking mode should be fine, if
that gives you a way to poll whether there is data available. 

> However, from the source code I got the impression that it is sufficient
> to detect EOF because can_read() only checks if some bytes are waiting
> to be read, so the subsequent read() can still block on the second byte
> of the stream. This means, we can probably get away with a simple
> read-ahead mechanism: can_read() does a blocking read(1) and stores it,
> and the next Procotol.read(n) returns the stored byte appended with
> read(n-1).
This is not a file but a stream. Not being able to read from it does not
necessarily imply EOF. Attempting to read a single byte will mean
blocking until the other side provides that byte, while we could be
spending that time crunching data. The second byte could indeed block as
well, but because of the way the protocol works this will not be the
case (a packet is always at least 4 bytes).

> I am attaching a hacked version of client.py, which implements the
> mechanism as an alternative SubprocessWrapper for the Windows platform.
> You can diff the file against dulwich 0.6.2.
Can you please attach diffs instead? They're much easier to read and
review.

Cheers,

Jelmer

Attachment: signature.asc
Description: This is a digitally signed message part