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.
Brane
Received on Sat Oct 21 14:36:08 2006