[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Delta window changes and delta applicator

From: Branko Čibej <brane_at_xbc.nu>
Date: 2000-09-19 18:45:11 CEST

Greg Hudson wrote:
> Having a pull-style interface for one function and a push-style
> interface for the other means we can't write code like, say, a delta
> applicator which works for both.
You could be right, I couldn't say. I'm not the author of those
interfaces, so I'll reserve my comments. Maybe this way is easier for
the delta walker?

> > I must say I absolutely hate seeing min/max macros [...]
> I'm not too enamored of them either. I'll look for alternatives along
> the lines of what you say.
(I apologise for my rather undiplomatic comment. I should have chosen my
words more carefully; "hate" does have unfortunate personal connotations.)

> >> IMO it would be better to impose that restriction on the generic
> >> read/write functions.
> > That's fine with me if it's fine with other people.
> Hm, I'm still okay with doing this, but I want to state one
> reservation: this makes generic read/write functions inappropriate to
> use in non-blocking situations, e.g. when the input source is a
> network socket and you don't want your execution thread to block
> reading from it. I don't know if we have any situations like that or
> not.
I've found non-blocking I/O useful only for polling several data
streams, or scheduling within a single-threaded environment. The typical
stream consumer or producer shouldn't have to deal with that; the
creator of the reader/writer will. Setting timeouts on the I/O
operations should be good enough for error recovery (e.g., from a broken
network connection), IMO. If you don't want an operation to block, just
fork off a process or create a thread for it. Anything else complicates
the code.

Received on Sat Oct 21 14:36:08 2006

This is an archived mail posted to the Subversion Dev mailing list.