dulwich-users team mailing list archive

[Dave Borowitz <dborowitz@xxxxxxxxxx>]

On Thu, Nov 11, 2010 at 12:03, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:

> 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).
>

FYI, there is also ReceivableProtocol.recv(), which is guaranteed to not
block but may return zero 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dulwich-users
> Post to     : dulwich-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dulwich-users
> More help   : https://help.launchpad.net/ListHelp
>
>