Re: Stream venting (long)

[robert_dewar@my-dejanews.com]

In article <76de7d$opb$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

> Hmm. It appears you think my problem is with
> algorithmicly handling the clients locking when locking
> is happening interally already. That's not the case; my
> problem is making the clients do their own pre- and
> postprocessing. That's a crappy interface. My code should
> be handling messy details like that for them (not so
> incidently, removing one possible source for errors).
> They should just be able to do a 'Write on their data
> structure and be done with it.

I agree, a crappy interface, why on earth would you do it
that way. The details of the locking should be buried in
the stream attribute routines that you write. If you want
the locking mechanism to be general, you could even make
an extended stream type that had the necessary lock field,
but most likely it would be perfectly convenient to just
use a single global lock.

I really don't see a significant problem here, it seems a
straightforward programming excercise, but most certainly
you don't want the client calling the stream routine to
have to do the locking, and of course (reread my messages)
I never suggested such a thing -- that was your suggestion!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own